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Preface 

LOPSTR’98 (see http://www.csd.uu.se/~pierref/lopstr98/) was the 8th edi- 
tion of the LOPSTR workshop series (see http://www.cs.man.ac.uk/~kung- 
kiu/lopstr/). In order to reflect the current emphasis on computational logic, 
the series was renamed Logic-based Program Synthesis and Transformation, as 
opposed to the former Logic Program Synthesis and Transformation. This means 
that papers on any computational-logic-based techniques, languages, and tools 
for the interactive or automated development of any kinds of programs were 
now solicited. There was also strong encouragement to submit papers discussing 
programming-in-the-large issues or practical applications. 

The selection process ran in three phases. First, based on the submitted 36 ex- 
tended abstracts, the programme committee invited 27 author teams to present 
their research at the workshop; pre- workshop proceedings with the accepted ab- 
stracts were available as a technical report (see ftp://ftp.cs.man.ac.uk/pub/TR/ 
UMCS-98-6-l.html). The revised and extended scope triggered abstracts from 
all continents, including 50% from outside the “usual geographic sphere of in- 
fluence” of LOPSTR. Also, 66% of these abstracts were written by first-time 
LOPSTR author teams. These figures seem to prove the effectiveness of the 
changes operated by the 1998 programme committee. Secondly, shortly after the 
workshop, the programme committee invited the authors of the 24 most promis- 
ing abstracts and presentations to submit full papers. Thirdly, after a round of 
conference-level refereeing, the 16 best full papers were included in this volume, 
which constitutes thus the post- workshop proceedings. Another 8 short papers 
appear in this volume, written by the invited speaker (see below), by authors 
who voluntarily refrained from writing the solicited full paper, and by authors 
whose full papers were not accepted (they appear in no particular order). 

As a workshop, LOPSTR’98 continued the tradition of being a lively and 
friendly forum for presenting recent and current research, as well as discussing 
future trends in the synthesis and transformation of programs. There were nine 
sessions, called Speciflcation, Synthesis, Transformation, Analysis, Synthesis & 
Schemas, Veriflcation, Specialisation, Composition & Reuse, and Industrial Ap- 
plications, hence covering larger ground than usual, with the first (massive) 
appearance of papers exploiting constraint technology, discussing pragmatics 
and real-life applications, addressing speciflcation language issues, or covering 
component-based software development. 

The invited speaker was Pierre Wolper, of the Universite de Liege in Belgium. 
He discussed his perspective on algorithms for synthesising reactive systems, by 
first reviewing the main results from that area and then, provocatively, but 
in a down-to-earth manner, trying to identify the main reasons for their non- 
exploitation. 

Steve Roach (NASA Ames) went through many iterations of a very im- 
pressive demonstration of the Amphion program synthesiser (see http://ic- 
www.arc.nasa.gov/ic/projects/amphion/), showing how it is, for instance, in 
day-to-day use at NASA for generating, through much reuse, programs from 
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graphical specifications provided by space scientists who have no background in 
computational logic or software engineering. 

LOPSTR’98 was organised by the Department of Computer Science of the 
University of Manchester, and took place in parallel to JICSLP’98 (the Joint 
International Conference and Symposium on Logic Programming), from 15 to 
19 June 1998. Delegates to one event could freely attend all sessions of the other 
event. Many of the JICSLP’98 participants were frequently observed to prefer 
the LOPSTR’98 sessions. 

LOPSTR’98 also coincided with the celebrations of the 50th anniversary of 
the world’s first stored-program computer, the Baby, built at Manchester in 1948 
(see http://www.computer50.org/). The delegates had the opportunity to attend 
a promenade concert given by the Halle Orchestra, as well as the magnificent 
Golden Anniversary Celebration at the Bridgewater Hall. The latter featured a 
dramatic reconstruction of the invention of the Baby, the switching-on of a replica 
of the Baby by its original co-builder Prof. Tom Kilburn, lively presentations by 
UK industry leaders about the role of computers in the future, and the conferral 
of several honorary degrees. 

The future of LOPSTR and its possible rapprochement with the IEEE inter- 
national conferences on Automated Software Engineering (ASE, formerly KBSE: 
Knowledge-Based Software Engineering, see http://www.sigart.acm.org/ Con- 
ferences/ ase/past/) were discussed in the JICSLP’98 post-conference workshop 
on Automated Software Engineering and Logic Programming. See http://www.es. 
man.ac.uk/~kung-kiu/ase-lp/ for the record of this meeting. 

LOPSTR’98 was sponsored by the Association for Logic Programming, the 
ESPRIT Network of Excellence in Computational Logic, and the Prolog Devel- 
opment Center, whose contributions are here gratefully acknowledged. 

I also want to take this opportunity to formally thank the workshop chair, 
Kung-Kiu Lau, and his team, Ian Pratt and Lynn Howarth, for a fabulously 
smooth event. My thanks also go to Francesca Toni and David Pearce for their 
help, to the programme committee for invaluable assistance with the academic 
aspects of the workshop, including three rounds of refereeing, and to Norbert E. 
Fuchs, the chairman of LOPSTR’97, for his helpful advice. 



December 1998 



Pierre Flener 
Programme Chair 
LOPSTR’98 
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Abstract. The specification language Attempto Controlled English 
(ACE) is a controlled natural language, i.e. a subset of standard En- 
glish with a domain-specific vocabulary and a restricted grammar. The 
restriction of full natural language to a controlled subset is essential for 
ACE to be suitable for specification purposes. The main goals of this re- 
striction are to reduce ambiguity and vagueness inherent in full natural 
language and to make ACE computer processable. ACE specifications 
can be unambiguously translated into logic specification languages, and 
can be queried and executed. In brief, ACE allows domain specialists to 
express specifications in familiar natural language and combine this with 
the rigour of formal specification languages. 



1 Introduction 

Specifications state properties or constraints that a software system must satisfy 
to solve a problem [IEEE 91], describe the interface between the problem domain 
and the software system [Jackson 95], and define the purpose of the software 
system and its correct use [Le Charlier & Flener 98]. In which language should 
we express specifications to accommodate these demands? 

The answer to this question depends on many factors, particularly on the 
specifiers and their background. Though many programs are specified by software 
engineers, often domain specialists — electrical engineers, physicists, economists 
and other professionals — perform this task. There are even situations where 
software engineers and knowledge engineers are deliberately replaced by domain 
specialists since they are the ultimate source of domain knowledge [Businger 
94]. One major goal of our research is to make formal specification methods 
accessible to domain specialists in notations that are familiar to them and that 
are close to the concepts and terms of their respective application domain. 

Traditionally, specifications have been expressed in natural language. Natu- 
ral language as the fundamental means of human communication needs no extra 
learning effort, and is easy to use and to understand. Though for particular do- 
mains there are more concise notations, natural language can be used to express 
any problem. However, experience has shown that uncontrolled use of natural 
language can lead to ambiguous, imprecise and unclear specifications with pos- 
sibly disastrous consequences for the subsequent software development process 
[Meyer 85]. 
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Formal specification languages — often based on logic — have been ad- 
vocated because they have an unambiguous syntax and a clean semantics, 
and promise substantial improvements of the software development process [cf. 
www.comlab.ox.ac.uk/archive/formal-methods]. In particular, formal specifica- 
tion languages offer support for the automatic analysis of specifications such as 
consistency verification, and the option to validate specifications through execu- 
tion [Fuchs 92]. Nevertheless, formal specification languages suffer from major 
shortcomings — they are hard to understand and difficult to relate to the applica- 
tion domain, and need to be accompanied by a description in natural language 
that “explains what the specification means in real-world terms and why the 
specification says what it does” [Hall 90] . Similar observations were made earlier 
by [Balzer 85] and by [Deville 90] . 

It seems that we are stuck between the over-flexibility of natural language 
and the potential incomprehensibility of formal languages. While some authors 
claim that specifications need to be expressed in natural language and that for- 
mal specifications are a contradiction in terms [Le Charlier & Flener 98], other 
authors just as vigorously defend the appropriateness of formal specification 
methods [Bowen & Hinchey 95a; Bowen & Hinchey 95b]. We, however, are con- 
vinced that the advantages of natural and formal specification languages should 
be and can be combined, specifically to accommodate the needs of domain spe- 
cialists. 

Our starting point lies in the observation that natural language can be used 
very precisely. Examples are legal language and the so-called controlled lan- 
guages used for technical documentation and machine translation [cf. www- 
uilots.let.ruu.nl/'Controlled-languages]. These languages are usually ad hoc de- 
fined and rely on rather liberal rules of style and on conventions to be enforced 
by humans. Taking these languages as a lead we have defined the specification 
language Attempto Controlled English (ACE) — a subset of standard English 
with a domain-specific vocabulary and a restricted grammar in the form of a 
small set of construction and interpretation rules [Fuchs et al. 98; Schwitter 98]. 
ACE allows users to express specifications precisely, and in the terms of the 
application domain. ACE specifications are computer-processable and can be 
unambiguously translated into a logic language. Though ACE may seem infor- 
mal, it is a formal language with the semantics of the underlying logic language. 
This also means that ACE has to be learned like other formal languages. 

There have been several projects with similar aims, but in most cases the sub- 
sets of English were not systematically and clearly defined. For example, [Macias 
& Pulman 95] developed a system which resembles ours with the important dif- 
ference that their system restricts only the form of composite sentences, but 
leaves the form of the constituent sentences completely free. As a consequence, 
the thorny problem of ambiguity remains and has to be resolved by the users 
after the system has translated the specification into a formal representation. 

The rest of the paper is organised as follows. In section 2 we motivate the tran- 
sition from full English to Attempto Controlled English and present a glimpse 
of ACE. Section 3 describes the translation of ACE specifications into discourse 
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representation structures and into other logic languages. In section 4 we outline 
the semantics of ACE specifications. Section 5 overviews querying and executing 
specifications. Finally, in section 6 we conclude and address further points of 
research. The appendix contains a complete example of an ACE specification 
together with its translation into the logic language of discourse representation 
structures. 

2 Prom English to Attempto Controlled English 

First, we will introduce Attempto Controlled English (ACE) by an example 
and then summarise its main characteristics. More information can be found in 
[Fuchs et al. 98; Schwitter 98]. 



2.1 An Example 

Specifications, and other technical texts, written in full natural language tend 
to be vague, ambiguous, incomplete, or even inconsistent. Take for example the 
notice posted in London underground trains [Kowalski 90] : 

Press the alarm signal button to alert the driver. 

The driver will stop immediately if any part of the train is in a station. 

If not, the train will continue to the next station where help can be more 
easily given. 

There is a £50 penalty for improper use. 

The notice leaves many assumptions and conclusions implicit. Kowalski shows 
that clarity can be improved, ambiguity reduced, and assumptions and conclu- 
sions made explicit when one follows guidelines for good language use. To do so, 
Kowalski reformulates the notice in the declarative form of logic programs. Take 
for instance the first part of the third sentence. Filling in the missing condition 
referred to by not, Kowalski rewrites it as 

The driver stops the train at the next station if the driver is alerted and not 
any part of the train is in a station. 

Though much improved even this sentence is incomplete since the agent who 
alerts the driver is still implicit. 

To eliminate this and other deficiencies of full natural language we have 
proposed the specification language Attempto Controlled English (ACE) as a 
well-defined subset of English. Since ACE is computer-processable we go beyond 
what [Kowalski 90] achieved — ACE specifications are not only clearer and 
more complete, but can also be automatically translated into a logic language, 
be queried and executed. 

Here is a version of the complete London underground notice in ACE. The 
third sentence is the one discussed above. Note that the agent who alerts the 
driver is now made explicit. 
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If a passenger presses an alarm signal button then the passenger alerts the 
driver. 

If a passenger alerts the driver of a train and a part of the train is in a 
station then the driver stops the train immediately. 

If a passenger alerts the driver of a train and no part of the train is in a 
station then the driver stops the train at the next station. 

If the driver stops a train in a station then help is available. 

If a passenger misuses an alarm signal button then the passenger pays a £50 
penalty. 

In the appendix you can find this ACE text together with its translation into 
the logic language of discourse representation structures. 



2.2 ACE in a Nutshell 

In this section we briefly present the components of ACE, viz. the vocabulary 
and the construction and interpretation rules. 



Vocabulary. The vocabulary of ACE comprises 

— predefined function words (e.g. determiners, conjunctions, prepositions), 

— user-defined, domain-specific content words (nouns, verbs, adjectives, ad- 
verbs) . 

Users can define content words with the help of a lexical editor that presupposes 
only basic grammatical knowledge. Alternatively, users can import existing lex- 
ica. 



Coustructiou Rules. The construction rules define the form of ACE sentences 
and texts, and state restrictions on the lexical and phrasal level. The construction 
rules are designed to avoid typical sources of imprecision in full natural language. 

ACE Specifications. An ACE specification is a sequence of sentences. There are 

— simple sentences, 

— composite sentences, 

— query sentences. 

Simple Sentences. Simple sentences have the form 

subject + verb + complements + adjuncts 

where complements are necessary for transitive or ditransitive verbs and adjuncts 
are optional. Here is an example for this sentence form: 

The driver stops the train at the station. 
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Composite Sentences. Composite sentences are built from simpler sentences with 
the help of predefined constructors: 

— coordination (and, or), 

— subordination by conditional sentences (if . . . then . . . ), 

— subordination by subject and object modifying relative sentences (who, 
which, that), 

— verb phrase negation (does not, is not), 

— noun phrase negation (no), 

— quantification (a, there is a, every, for every). 

Query Sentences. There are 

— 2/es/no-queries, 

— ui/i-queries. 

Fes/no-queries are derived from simple sentences by inverting the subject and 
the verb be (Is the train in the station?), or by inserting do or does if the verb 
is not be (Does the driver stop the train?). Wi-queries begin with a so-called 
w/i-word (who, what, when, where, how, etc.) and contain do or does (Where does 
the driver stop the train?), unless the query asks for the subject of the sentence 
(Who stops the train?). 

Anaphora. ACE sentences and phrases can be interrelated by anaphora, i.e. 
by references to previously occurring noun phrases. Anaphora can be personal 
pronouns or definite noun phrases. In 

A passenger of a train alerts a driver. He stops the train. 

the personal pronoun he refers to the noun phrase a driver and the definite noun 
phrase the train refers to the indefinite noun phrase a train. 

Coordination. Coordination is possible between sentences and between phrases 
of the same syntactic type, e.g. 

A passenger presses an alarm signal button and the driver stops the train. 

A passenger presses an alarm signal button and alerts the driver. 

A driver stops a train immediately or at the next station. 

Coordination of verbal phrases can be simplified. Instead of 

A passenger presses a red button or presses a green button. 

we can write 

A passenger presses a red button or a green button. 
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Lexical Restrictions. Examples for lexical restrictions and typographical conven- 
tions are: 

— verbs are used in the simple present tense, the active voice, the indicative 
mood, the third person singular (presses), 

— no modal verbs (may, can, must etc.) or intensional verbs (hope, know, believe 
etc.), 

— no modal adverbs (possibly, probably etc.), 

— ACE allows the user to define synonyms (alarm signal button, alarm button) 
and abbreviations (ASB standing for alarm signal button), 

— content words can be simple (train) or compound (alarm signal button, alarm- 
signal-button). 

Phrasal Restrictions. Examples for phrasal restrictions are: 

— complements of full verbs can only be noun phrases (press a button) or prepo- 
sitional phrases (send the ambulance to the station), 

— adjuncts can only be realised as prepositional phrases (in a station) or adverbs 
(immediately), 

— o/-constructions (the part of the train) are the only allowed postnominal 
prepositional modifiers. 



Interpretation Rules. Interpretation rules control the semantic analysis of 
grammatically correct ACE sentences. They, for example, resolve ambiguities 
that cannot be removed by the construction rules. The result of this analysis is 
reflected in a paraphrase. Important rules are: 

— verbs denote events (press) or states (be), 

— the textual order of verbs determines the default temporal order of the as- 
sociated events and states, 

— prepositional phrases in adjunct position always modify the verb, e.g. give 
additional information about the location of an event (The driver {stops the 
train in a station}.), 

— anaphoric reference is possible via pronouns or definite noun phrases; the 
antecedent is the most recent suitable noun phrase that agrees in number 
and gender, 

— noun phrase coordination within a verb phrase is interpreted as coordination 
reduction; the elided verb is distributed to each conjunct (The driver presses 
a red button and [presses] a green button.), 

— the textual occurrence of a quantifier (a, there is a, every, for every) opens its 
scope that extends to the end of the sentence; thus any following quantifier 
is automatically within the scope of the preceding one. 



Learning ACE. In contrast to rules of formal languages the construction and 
interpretation rules of ACE are easy to use and to remember since they are 
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similar to English grammar rules and only presuppose basic grammatical knowl- 
edge. One should bear in mind, however, that in spite of its appearance ACE 
is a formal language that — like other formal languages — must be learned. 
Companies like Boeing and Caterpillar have been using controlled languages for 
technical documentation for many years. They report that these languages can 
be taught in a few days, and that users get competent in a few weeks [CLAW 
98] . Thus we claim that domain specialists need less effort to learn and to apply 
the rules of ACE than to cope with an unfamiliar formal language. 

3 Prom ACE to Discourse Representation Structures 

ACE sentences are translated into discourse representation structures — a syn- 
tactical variant of full first-order predicate logic. We will first discuss the trans- 
lation process, and then the handling of ambiguity. 



3.1 Translation 

ACE specifications are analysed and processed deterministically by a unification- 
based phrase structure grammar enhanced by linearised feature structures writ- 
ten in GULP, a preprocessor for Prolog [Covington 94] . Unification-based gram- 
mars are declarative statements of well-formedness conditions and can be com- 
bined with any parsing strategy. Prolog’s built in top-down recursive-descent 
parser uses strict chronological back-tracking to parse an ACE sentence. Top- 
down parsing is very fast for short sentences but for longer composite sentences 
the exponential costs of backtracking can slow down the parsing. It turns out 
that we can do better using a hybrid top-down chart parser that remembers 
analysed phrases of an ACE sentence. Actually, the chart is only used if it is 
complete for a particular phrase type in a specific position of an ACE sentence 
— otherwise the Attempto system parses the sentence conventionally. 

Correct understanding of an ACE specification requires not only processing 
of individual sentences and their constituents, but also taking into account the 
way sentences are interrelated to express complex propositional structures. It is 
well-known that aspects such as anaphoric reference, ellipsis and tense cannot be 
successfully handled without taking the preceding discourse into consideration. 
Take for example the discourse 

A passenger enters a train. The train leaves a station. 

In classical predicate logic these two sentences would be represented as two 
separate formulas 

3X3Y {passenger{X) A train{Y) A enter {X, F)) 

3U3W {train{U) A station{W) A leave{U, W)) 



This representation fails to relate the anaphoric reference of the definite noun 
phrase the train in the second sentence to the indefinite noun phrase a train in 
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the first sentence. We solve this problem by employing discourse representation 
theory that resolves anaphoric references in a systematic way combining the two 
propositions into one [Kamp & Reyle 93] . 

In our case, ACE sentences are translated into discourse representation theory 
extended by events and states (DRT-E) [cf. Kamp & Reyle 93, Parsons 94]. 
DRT-E is a variant of predicate logic that represents a multisentential text as 
a single logical unit called a discourse representation structure (DRS). Each 
part of an ACE sentence contributes some logical conditions to the DRS using 
the preceding sentences as context to resolve anaphoric references. A DRS is 
represented by a term drs(U,Con.) where U is a list of discourse referents and 
Con is a list of conditions for the discourse referents. The discourse referents 
are quantified variables that stand for objects in the specified domain, while the 
conditions constitute constraints that the discourse referents must fulfill to make 
the DRS true. Simple DRS conditions are logical atoms, while complex DRS 
conditions are built up recursively from other DRSs and have the following forms 
ifthen(DRSl,DRS2), or(DRSl,DRS2, ■ ■ ■ ), not(DRS), ynq(DRS) and whq(DRS) 
representing conditional sentences, disjunctive phrases, negated phrases, yes/no- 
queries, and w/i-queries. 

The translation of the two ACE sentences 

A passenger enters a train. The train leaves a station. 

generates the DRS 

[A,B,C,D,E] 
passenger (A) 
train(B) 

event (C , enter (A , B) ) 

station (D) 

event (E , leave (B , D) ) 

The first ACE sentence leads to three existentially quantified discourse referents 
( [A , B , C] ) and the first three conditions of the DRS. The second ACE sentence is 
analysed in the context of the first sentence. It contributes two further discourse 
referents ([D,E]) and the fourth and the fifth condition of the DRS. The two 
event conditions have been derived from lexical information that classifies the 
verbs enter and leave as being associated with events. 

Analysing the second sentence in the context of the first one allows the At- 
tempto system to resolve the train as anaphoric reference to a train. The search 
space for antecedents of anaphora is defined by an accessibility relation among 
nested DRSs. A discourse referent is accessible from a DRS D if the discourse 
referent is in D, in a DRS enclosing D, in a disjunct that precedes D in an 
or-DRS, or in the antecedent of an z/t/ien-DRS with D as consequent. The reso- 
lution algorithm always picks the closest accessible referent that agrees in gender 
and number with the anaphor. 

Here is a more complex example from the ACE version of the underground 
notice. The sentence 
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If a passenger alerts a driver of a train then the driver stops the train in a 
station. 

is translated into the DRS 

[] 

IF 

[A,B,C,D] 
passenger (A) 
driver (B) 
train(C) 
of (B,C) 

event (D , alert (A , B) ) 

THEN 

[E,F] 

station(E) 
event (F , stop (B , C) ) 
locationCF, in(E) ) 

The outermost DRS has an empty list of discourse referents and an ifthen-DRS 
as condition. Both the z/-part and the then-part are DRSs. The discourse refer- 
ents ( [A , B , C , D] ) occurring in the z/-part of the DRS are universally quantified, 
while the discourse referents ([E,F]) in the then-part of the DRS are existen- 
tially quantified. The prepositional phrase in a station leads to the condition 
station(E) and to the predefined condition locationCF, in(E) ) that indicates 
the location of the event F. The Attempto system resolves the driver and the train 
as anaphoric references to a driver and to a train, respectively. 

A DRS can be automatically translated into the standard form of first-order 
predicate logic and into clausal form. ACE sentences without disjunctive conse- 
quences lead to Prolog programs. 



3.2 Constraining Ambiguity 

Ambiguity is the most prevalent problem when natural language is processed by 
a computer. Though ambiguity occurs on all levels of natural language, here we 
will only discuss a case of syntactical ambiguity. Take the three sentences 

The driver stops the train with the smashed head-light. 

The driver stops the train with great effort. 

The driver stops the train with the defect brake. 

Note that all three sentences have the same grammatical structure, and that 
all three sentences are syntactically ambiguous since the prepositional phrase 
with. . . can be attached to the verb stops or to the noun train. A human reader 
will perceive the first and the second sentence as unambiguous since each sen- 
tence has only one plausible interpretation according to common sense, while 
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the third sentence allows two plausible interpretations since with the defect brake 
can refer to stops or to train. For this sentence additional contextual knowl- 
edge is necessary to select the intended interpretation. Altogether, we find that 
humans can disambiguate the three sentences with the help of contextual, i.e. 
non-syntactical, knowledge. 

Standard approaches to handle ambiguity by a computer rely on Generate 
and Test or on Underspecified Representations. 

Generate and Test. The traditional account is first to generate all possible 
interpretations, and then to eliminate those which are not plausible. The elimina- 
tion of implausible interpretations can be done by presenting all interpretations 
to the user who selects the intended one [e.g. Macias & Pulman 95], or by formal- 
ising relevant contextual knowledge and automatically selecting the most fitting 
interpretation on the basis of this knowledge [e.g. Hindle & Rooth 93]. Generate 
and Test suffers from several shortcomings: it is inefficient and can lead to the 
combinatorial explosion of interpretations; manually selecting one of many in- 
terpretations is a burden on the user; formalising relevant contextual knowledge 
for the automatic disambiguation is difficult. 

Underspecified Representations. A sentence gets just one semantic represen- 
tation based on its syntactic form leaving certain aspects of the meaning unspec- 
ified [Alshawi 92; Reyle 93]. Fully specified interpretations are obtained by filling 
in material from formalised contextual knowledge. This approach has a drawback 
that we encountered already: it is difficult to formalise rules that lead to more 
specific interpretations because complex contextual effects — world knowledge, 
linguistic context, lexical semantics of words etc. — play a crucial role in the 
human disambiguation process. 

In approaches based on Generate and Test or on Underspecified Representa- 
tions disambiguation depends in one way or other on context. Thus the same 
syntactic construct could get different interpretations in different contexts which 
are perhaps only vaguely defined [Hirst 97] . This may be desirable for the process- 
ing of unrestricted natural language but is highly problematic for specifications. 
Writing specifications is already very hard. If on top of this the specification lan- 
guage allowed context-dependent interpretations then writing, and particularly 
reading, specifications would indeed be very difficult, if not entirely impossible. 

To avoid this problem, ACE resolves ambiguity by a completely syntactical 
approach without any recourse to the context. 

More concretely, ACE employs three simple means to resolve ambiguity: 

— some ambiguous constructs are not part of the language; unambiguous al- 
ternatives are available in their place, 

— all remaining ambiguous constructs are interpreted deterministically on the 
basis of a small number of interpretation rules that use syntactic information 
only; the interpretations are reflected in a paraphrase, 

— users can either accept the assigned interpretation, or they must rephrase 
the input to obtain another one. 
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For the third example sentence 

The driver stops the train with the defect brake. 

the Attempto system would generate the paraphrase 

The driver {stops the train with the defect brake}. 

that reflects ACE’s interpretation rule that a prepositional phrase always modi- 
fies the verb. This interpretation is probably not the one intended by the user. To 
obtain the other interpretation the user can reformulate the sentence employing 
the interpretation rule that a relative sentence always modifies the immediately 
preceding noun phrase, e.g. 

The driver stops the train that has a defect brake. 

yielding the paraphrase 

The driver stops {the train that has a defect brake}. 

Altogether, ACE has just over a dozen interpretation rules to handle ambiguity. 

4 Semantics of ACE Specifications 

In this chapter we introduce the model-theoretic interpretation of ACE, and 
explain ACE’s model of time, events and states. 



4.1 Model-Theoretic Interpretation 

A discourse representation structure is a syntactic variant of full first-order predi- 
cate logic and thus allows for the usual model-theoretic interpretation. According 
to [Kamp & Reyle 93] any interpretation of a DRS is also an interpretation of 
the text from which the DRS was derived. Concretely, we have the following 
definition: 

Let D be the DRS derived from the set S of ACE sentences with the 
vocabulary V, and M be a model of V. Then S is true in M iff D is true 
in M. 

Thus we can associate meaning to ACE specifications in a way that is completely 
analogous to the model-theoretic interpretation of logic formulas. We can give 
each ACE sentence a truth value, i.e. we call a sentence true if we can interpret 
it as describing an actual state of affairs in the specified domain, or we label the 
sentence false if we cannot establish such an interpretation. 

We can interpret simple sentences as descriptions of distinct events or states. 
The sentence 



A driver stops a train. 
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is true if the word driver can be interpreted as a relation driver that holds for 
an object A of the specified domain, the word train as a relation train that 
holds for an object B of the specified domain, and the word stop as a relation 
stopping event that holds between A and B. Otherwise, the sentence is false. 

Once we have assigned meaning to simple sentences we can give meaning 
to composite sentences. Again, this is completely analogous to classical model 
theory. A conjunction of sentences is true if all conjoined sentences are true. A 
disjunction of sentences is true if at least one of the sentences of the disjunction 
is true. A sentence with a negation is true if the sentence without the negation 
is false. An ifthen-sentence is only false if the z/-part is true and the then- 
part is false; otherwise, the ifthen-sentence is true. A sentence with a universal 
quantifier is true if the sentence without the universal quantifier is true for all 
objects denoted by the quantified phrase. 



4.2 Events and States 

Attempto Controlled English has a model of time, events and states that closely 
resembles that one of the event calculus [Sadri & Kowalski 95] . 

Each verb in a sentence denotes an event or a state. Events occur instanta- 
neously, while states — i.e. relations that hold or do not hold — last over a time 
period until they are explicitly terminated. 

Each occurrence of a verb is implicitly associated with a time. If the verb 
denotes an event this is the time point at which the event occurs; if the verb 
denotes a state this is the time point from which on the state holds. 

Per default the textual order of verbs establishes the relative temporal order 
of their associated events or states. E.g. in 

A passenger alerts a driver. The driver stops a train. The train is in a station. 

the event alert is temporally followed by the event stop which is temporally 
followed by the onset of the state be in a station. Our default assumption “textual 
order = temporal order” is supported by psychological and physiological evidence 
[Miinte et al. 98]. 

Users can override the default temporal order by explicitly specifying times 
through prepositional phrases like at 9 o'clock, and by adding prepositional 
phrases like at the same time, or in any temporal order. A future version of ACE 
will allow users to combine sentences with the help of temporal prepositions like 
before, after and while. 

5 Deductions from Discourse Representation Structures 

We describe how deduction from discourse representation structures can be used 
to answer queries, to perform hypothetical and abductive reasoning, and to exe- 
cute a specification. Furthermore, we briefly indicate how users can define domain 
theories and ontologies. 




Attempto Controlled English 



13 



5.1 Theorem Prover for Discourse Representation Structures 

On the basis of a proposal by [Reyle & Gabbay 94] we have developed a correct 
and complete theorem prover for discourse representation structures. To prove 
that a discourse representation structure DRS2 can be derived from a discourse 
representation structure DRSl 

DRSl h DRS2 

the theorem prover proceeds in a goal-directed way without any human inter- 
vention. In the simplest case an atomic condition of DRS2 is a member of the 
list of conditions of DRSl — after suitable substitutions. In other cases, the left 
or the right side of the turn-stile are reformulated and simplified, e.g. we replace 



Lh {RIV R2) 


by 


L h R1 and L h R2 


L'r{Rl^ R2) 


by 


{L\JR1) h R2 



This theorem prover will form the kernel of a general deduction system for 
DRSs. The deduction system will answer queries, perform hypothetical reason- 
ing (‘What happens if ... ?’), do abductive reasoning (‘Under which conditions 
does . . .occur?’), and execute specifications. All interactions with the deduction 
system will be in ACE. 



5.2 Query Answering 

A specification in a logic language describes a particular state of affairs within a 
problem domain. We can examine this state of affairs and its logical consequences 
by querying the specification in ACE. ACE allows two forms of queries 

— yes/no-qaeiies asking for the existence or non-existence of the state of affairs 
defined by the ACE specification, 

— ui/i-queries (who, what, when, where, how, etc.) asking for specific details of 
the state of affairs described by the ACE specification. 

Here is an example of a w/i-query. Once we have translated the ACE sentence 

A passenger enters a train. 

into the DRS S 

[A,B,C] 
passenger (A) 
train(B) 

event (C , enter (A , B) ) 



we can ask 
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Who enters a train? 

The query sentence is translated into the DRS Q 

[] 

WHQ 

[A,B,C] 
who (A) 
train(B) 

event (C , enter (A , B) ) 
and answered by deduction 

5hg 

Query words — like who — are replaced during the proof and answers are 
returned to the user in ACE, i.e. 

[A passenger] enters a train. 



5.3 Hypothetical Reasoning 

When a logic specification partially describes a state of affairs there can be 
various possibilities to extend the specification. These extensions can lead to 
diverse logical consequences, some of which are desirable, while others are not. 
That is, we may want to ask the question ‘What happens if . . . ?’. 

‘What happens if . . . ?’ questions mean that we test a particular hypothe- 
sis H by examining its implied consequence C in the context of a given logic 
specification S. 

Sh{H^C) 

With the help of the deduction theorem this can be restated as 
{SUH)hC 

i.e. we derive the logical consequence C of the union of S and H. 

Here is a simple example shown on the level of ACE. If we extend the speci- 
fication 

If a passenger alerts a driver then the driver stops a train, 
by the sentence 

A passenger alerts a driver, 
then we can deduce the ACE sentence 
A driver stops a train. 



as the logical consequence of the specification and its extension. 
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5.4 Abductive Reasoning 

Once we have devised a logic specification we may want to investigate under 
which conditions a certain state of affairs occurs. If the conditions are already 
described by the logic specification we have the situation of a simple query. 
However, if the specification does not yet contain the pre-conditions of the state 
of affairs we are interested in then the question ‘Under which conditions does ... 
occur?’ can lead to abductive extensions of the specification. 

Abduction investigates under which conditions A we can derive a particular 
consequence C from the logic specification S. 

(SuA)hC 

Again a simple example. Given the specification 

If a passenger alerts a driver then the driver stops a train. 

If a train arrives at a station then a driver stops the train. 

we want to know under which conditions the state of affairs occurs that is de- 
scribed by the sentence 

A driver stops a train. 

Abduction will give us first the ACE sentence 
A passenger alerts a driver, 
and then the ACE sentence 
A train arrives at a station, 
as two possible conditions. 



5.5 Executing an ACE Specification 

Model-oriented logic specifications build a behavioural model of the program to 
be developed [Wing 90] , and one might be interested in executing this model to 
demonstrate its behaviour, be it for validation, or for prototyping. Formally, this 
form of execution is based on the refiexivity of the deduction relation. 

ShS 

The derivation succeeds trivially. However, it can be conducted in a way that the 
logical and the temporal structure of the specification are traced, and that users 
can convince themselves that the specification has the expected behaviour. Fur- 
thermore, if predicates have side-effects — i.e. operations that modify the state 
of the system such as input and output — these side-effects can be made visi- 
ble during the derivation. The concrete side-effects are realised by the execution 
environment. 

Executing the ACE specification 
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A passenger alerts the driver. The driver stops the train. The train is in the 
station. 

leads to the execution trace: 

event : A alerts B 

A: passenger 

B: driver 

event : B stops D 

D: train 

state: D is in F 

F: station 

Validating a specification can be difficult since users may find it hard to relate 
its logical consequences to the — possibly implicit or incomplete — require- 
ments. The Attempto system eases this task by expressing the execution trace 
in the terms of the problem domain. This not only reduces the semantic distance 
between the concepts of the application domain and the specification but also 
increases the efficiency of the validation process. 



5.6 Domain Knowledge 

The Attempto system is not associated with any specific application domain, nor 
with any particular software engineering method. By itself it does not contain any 
knowledge or ontology of application domains, of software engineering methods, 
or of the world in general. Thus users must explicitly define domain knowledge. 
Currently, this is possible with the help of ACE sentences like 

Waterloo is a station. 

Every train has a driver. 

Even constraints can be expressed. If a specification states in one place that a 
train is out of order, and in another place that at the same time the same train 
is available, the contradiction can be detected if we explicitly define that out of 
order and available exclude each other, e.g. 

No train is out of order and available at the same time. 

In the future, ACE will provide meta-statements like 

Define a train as a vehicle. 

which will allow users to define domain theories and ontologies more concisely. 
With other meta-statements users will be able to specify constraints, safety 
properties, and exceptions. 
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6 Conclusions 

We have developed Attempto Controlled English (ACE) as a specification lan- 
guage that combines the familiarity of natural language with the rigour of formal 
specification languages. Furthermore, we have implemented the Attempto spec- 
ification system that allows domain specialists with little or no knowledge of 
formal specification methods to compose, to query and to execute formal spec- 
ifications using only the concepts and the terms of their respective application 
domain. 

The Attempto system translates ACE specifications into discourse represen- 
tation structures (DRSs). Being a variant of first-order predicate logic, DRSs 
can readily be translated into a broad range of other representations. While the 
Attempto system comprises an automatic translation of DRSs into first-order 
predicate logic, clausal logic and Prolog, other DRSs were manually translated 
into the input language of the Finfimo theorem prover [Bry et al. 98]. This means 
that ACE is not only a specification language but also a convenient means to 
express theorems, integrity constraints and rules. 

Currently, we are extending ACE with plurality and with complementary 
notations for graphical user interfaces and algorithms. Furthermore, we are in- 
vestigating ways how to structure large ACE specifications. 
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Appendix 

Original Version of the London Underground Notice 
Press the alarm signal button to alert the driver. 

The driver will stop immediately if any part of the train is in a station. 

If not, the train will continue to the next station where help can be more easily given. 
There is a £50 penalty for improper use. 

ACE Version with Sentence by Sentence Translation into DRSs 
If a passenger presses the alarm signal button then the passenger alerts the driver. 

[] 

IF 

[A,B,C] 
passenger (A) 
alarm_signal_button(B) 
event (C , press (A , B) ) 

THEN 

[D,E] 

driver (D) 

event (E, alert (A, D)) 

If a passenger alerts the driver of a train and a part of the train is in a station then the 
driver stops the train immediately. 

[] 

IF 

[A,B,C,D,E,F,G] 
passenger (A) 
driver (B) 
train(C) 
of (B,C) 

event (D, alert (A, B)) 
part (E) 
of (E,C) 
station(F) 
state (G,be (E) ) 
locationCG, in(F) ) 

THEN 

[H] 

event (H, stop(B,C) ) 
manner (H , immediately) 

If a passenger alerts the driver of a train and no part of the train is in a station then the 
driver stops the train at the next station. 

[] 

IF 

[A,B,C] 
passenger (A) 
driver (B) 
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train(C) 
of (B,C) 

event (D, alert (A, B)) 

IF 

[E] 

part (E) 
of (E,C) 

THEN 

[] 

NOT 

[F,G] 

station(F) 

state(G,be(E)) 

location(G,in(F)) 

THEN 

[H,I] 
next (H) 
station(H) 
event (I , stop(B,C) ) 
locationCl , at (H) ) 

If the driver stops the train in a station then help is available. 

[] 

IF 

[A,B,C,D] 
driver (A) 
train(B) 

event (C,stop(A,B)) 
station(D) 
locationCC, in(D) ) 

THEN 

[E,F] 

help(E) 

state (F, available (E) ) 



If a passenger misuses the alarm signal button then the passenger pays a £50 penalty. 

[] 

IF 

[A,B,C] 
passenger (A) 
alarm_signal_button(B) 
event (C,misuse(A,B) ) 

THEN 

[D,E] 

•f_50_penalty (D) 
event (E,pay (A,D) ) 
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Abstract. Declarative methodologies for logic program construction 
have been proposed for Prolog. They roughly consist of 1) building a 
purely logical version of the program based on a clear declarative se- 
mantics and 2) performing a number of checks about modes, types, ter- 
mination and multiplicity. We plan to define a similar methodology for 
Mercnry. This choice is motivated by the fact that type, mode, and mul- 
tiplicity must be explicitly specified in Mercury, allowing the compiler 
to perform the second step above. In order to propose a methodology 
to perform the first step, we need a declarative semantics for Mercury, 
which has not yet been explicitly defined. The goal of the paper is to 
propose snch a semantics pursuing simplicity and naturalness. We chose 
to define the semantics with respect to a unique interpretation domain, 
called the ’’universe”, which is a kind of higher-order version of the Her- 
brand universe. Based on this simple domain, the denotation of terms and 
goals is naturally defined as well as the models of programs. Although 
the declarative semantics is primarily introdnced to improve ’’mannal” 
program construction by programmers, it conld be used in a synthesis 
context. 



1 Introduction 

The work presented in this paper originates from two assumptions: 1) construct- 
ing logic programs requires some form of explicit reasoning (i.e., a logic program 
is not both a specification and a program, it is just a program); 2) logic pro- 
grams should be constructed according to a declarative approach that basically 
amounts to show that the model intended by the user (described through a 
specification) is a (distinguished) model of the program. 

Declarative methodologies for logic program construction have been proposed 
for Prolog (see e.g., ' ' ~l ). They roughly consist of 1) building a purely logical 

version of the program based on a clear declarative semantics and 2) performing 
a number of checks about modes, types, termination, and multiplicity, as well 
as some permutations of clauses and literals, to ensure that Prolog actually 
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computes the relation described by the logical version. We plan to define a 
similar methodology for Mercury This choice is motivated by the fact that 
type, mode, and multiplicity information can (and must) be explicitly specified 
in Mercury, allowing the compiler to automatically perform the second step 
described above. However, in order to propose a methodology to perform the 
first step, we need a declarative semantics for Mercury, which has not yet been 
explicitly defined. The goal of this paper is to propose such a semantics. 

When designing our declarative semantics for Mercury, we have pursued two 
main objectives: simplicity and naturalness. This is because, in our opinion, the 
declarative semantics should be a straightforward mathematical underpinning 
of the intuitive meaning of the programs, allowing the programmer to check 
his/her understanding of programs both easily and explicitly. As a consequence, 
we chose to define the semantics with respect to a unique interpretation domain, 
called the “universe” , which is a kind of higher-order version of the Herbrand 
universe used in e.g., Q. Based on this simple domain, the denotations of terms 
and goals (formulas) are naturally defined as well as the models of programs. 
In this paper, we present a declarative semantics for Mercury, T>o, which is not 
completely satisfactory because it does not handle polymorphism, but is simple 
enough to illustrate the basic intuition behind our final declarative semantics T>. 

Notice that, although the declarative semantics is primarily introduced to 
improve “manual” program construction by programmers, it could also be used 
in a synthesis context to automatically translate synthesized programs into 
equivalent Mercury programs (see Section H. 

The rest of this paper is organized as follows. SectionHintroduces the nota- 
tion used in the paper. SectionHpresents an adaptation of Deville’s methodology 
for Mercury program construction. SectionHpresents the definition of the declar- 
ative semantics T>o, whereas the declarative semantics T> is given in Section H 
Finally, Section H summarizes how we will use the declarative semantics in the 
program construction process. 



2 Notation 

Given two sets A and B, A ^ B is the set of total functions from A to B. If 
f G A ^ B then dom{f) = A is the domain of /. p(A) is the set of subsets of 
A and x indicates the Cartesian product of sets. A finite sequence xi,. . .,Xn 
of elements (e.g. Cartesian product of sets, tuples of elements) is indicated by 
X* or x^. The length of x* is denoted by |a;*|, whereas n is the length of a;”, {x 
y)* is an abbreviation for {x\,yi ), . . ., (a;„, y„) where n = |(a; y)*\. The empty 
sequence is denoted by f2. If / is an n-ary function with n > 1, then f{x*) 
and f[x* /d*] denote f{xi , . . . , X\x*\) and the function f that differs from / only 
on X* where f{x*) = d*, respectively. If / is a 1-ary function then f{x*) and 
f[x* /d*] denote the sequence f{xi ), . . . , f{x\x*\) and the function f that differs 
from / only for f'{xi) = di, . . . , f'{x\x*\) = d\d*\, respectively. In both notations, 
we assume that |a:*| = |d*|. 
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When presenting examples, the arity of every constructor, type constructor, 
and identifier will be specified with an integer: for instance, strange/2 means 
that (constructor, type constructor, or identifier) strange has arity 2. Bool 
denotes the set of boolean values { TRUE, FALSE}, A, and V denote negation, 
conjunction, and disjunction, respectively, in first order logic. IN and Z denote 
the sets of natural and integer numbers, respectively. Lis<(Z) and for all n G IN, 
Listni'^) indicate the set of lists of integers and the set of lists of integers having 
n elements, respectively. 



3 Deville’s Methodology for Mercury Program 
Construction 

3.1 Introduction 

We present the general guidelines of our proposal of Deville’s methodology for 
Mercury program construction and we compare them with Deville’s methodol- 
ogy for Prolog program construction Q. It is worthwhile to note that Deville’s 
methodology for Mercury program construction has not yet been well established 
and we will explain only the general points of our proposal. In the following, we 
will abbreviate Deville’s methodology for Prolog (Mercury) program construc- 
tion into Deville’s methodology for Prolog (Mercury). Figure O illustrates the 
main steps of Deville’s methodology for Prolog and Mercury. Both methodolo- 
gies are presented through three steps where the first one is the elaboration of a 
specification of a predicate. The second step of Deville’s methodology for Prolog 
(Mercury) consists of constructing a logic (declarative) description from which 
a Prolog (Mercury) program is derived in the last step. 

The specification in Deville’s methodology is composed of an informal de- 
scription of a relation and a description of types, directionality, and multiplicity 
of the predicate (or function) being defined. In FigureHinformal parts of specifi- 
cation are given in italic whereas formal parts are presented in typewriter. We 
observe that Prolog does not provide any language support for types, direction- 
ality, or multiplicity information, although that information can be built on top 
of Prolog, as it was done in Folon Q. On the contrary, information about types, 
directionality, and multiplicity is expressible in Mercury and, for the sake of sim- 
plicity, we directly copy that information both in the declarative description and 
in the final Mercury code. This can be done because we restrict types to what can 
be formally defined in Mercury. A more powerful methodology could arguably 
be based on types considered as arbitrary sets of ground terms as in but, 
for simplicity, we prefer to use directly Mercury type definitions. 

The second step of Deville’s methodology for Prolog is the construction of a 
logic description, which is a first order logic formula formalizing the information 
contained in the specification. The semantics of logic descriptions is based on 
Herbrand interpretations and models Q. The second step of Deville’s method- 
ology for Mercury is similar and consists of the construction of a declarative 
description. However, such declarative descriptions are higher order formulas. 
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Since there is no previously available semantics for such formulas, we provide a 
declarative semantics for Mercury, called T>, for formalizing the concept of sound 
and complete declarative description with respect to a specification. 



Prolog 



Type 

Relation 

Directionality 

Multiplicity 



First 

Order 

Logic 



Prolog 




Mercury 



{ Type 
Relation 
Directionality 
Multiplicity 



Declarative 
Semantics V 



Mercury 



Fig. 1. Deville’s Methodology for Prolog and Mercury 



The last step of Deville’s methodology for Prolog is the derivation of a Prolog 
program from a logic description. In order to obtain a correct Prolog program, 
a dataflow analysis (using the type and directionality information of the speci- 
fication) has to be performed to determine a permutation of the clauses and of 
the literals such that incompleteness, unfairness, unsoundness, and floundering 
problems do not occur. In the Mercury case, many transformations needed to 
obtain an operationally correct Mercury program are already performed by the 
existing Mercury compiler. In this paper, we focus on the second step of the 
methodology (declarative description and declarative semantics), disregarding 
the directionality and multiplicity parts of specification. 

We can summarize that Deville’s methodology for Mercury is obtained from 
Deville’s methodology for Prolog by replacing “logic description” with “declara- 
tive description”, “first order logic” with “higher order logic”, “Herbrand mod- 
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els” with “models in our declarative semantics” . Deville’s Methodology for Mer- 
cury is illustrated through the development of a Mercury (higher-order) declar- 
ative description in Section 

3.2 Example of Deville’s Methodology for Mercury 

We illustrate Deville’s Methodology for Mercury through the predicate map/3 
taking a function, a list of possible inputs for that function, and a corresponding 
list of outputs. Since the functional argument of map/3 is completely arbitrary, 
map/3 has a polymorphic type, i.e., its type contains type variables. 



predicate map (F , LI , L2) 

— Specification: 

• Type: 

F : func(Tl)=T2 
LI : list(Tl) 

L2 : list(T2) 

list(T) — > [] ; [Tllist(T)] 

• Relation: L2 = [F(Xi) ,... ,F(X„)] , where LI = [Xi,...,X„] 

— Declarative Description: 

F : func(Tl)=T2 
LI : list(Tl) 

L2 : list(T2) 

list(T) — > [] ; [Tllist(T)] 

map(F,Ll,L2) (LI = [] A L2 = [] ) V 

(LI = [X1IL3] A L2 = [X2IL4] A X2 = F(X1) A 
map(F,L3,L4) ) 

The first part of the declarative description contains information about types 
and it is exactly the same as the one in the specification. The construction 
of the second part of the declarative description follows the same guidelines 
as in Deville’s methodology for Prolog |. In this particular case, we use LI 
as induction parameter whereas “to be a proper suffix of” is the well-founded 
relation, needed in Deville’s methodology. The base case comes out immediately 
and notice that we do not check the type of F as it would be needed in Deville’s 
methodology for Prolog because we use a typed logic, and thus, the type of 
every variable (and identifier) is checked by a type system Q. The inductive 
case comes directly from the definition of the relation. Notice that F(X1) is a 
higher-order term, because F is a variable and not a functor. 

Apart from the last remark, we can say that the derivation step of Deville’s 
methodology for Prolog is converted into Deville’s methodology for Mercury with 
little effort. Also, the derivation of the Mercury code for map/3 is immediate using 
the declarative description: 
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type list(T) > [] ; [T|list(T)] 

pred mapCfunc (Tl) =T2 .list (Tl) , list (T2) ) . 
map(F,Ll,L2) (LI = [] , L2 = []) ; 

(LI = [X1IL3], L2 = [X2IL4], X2 = F(X1) , map(F,L3,L4) ) . 

4 First Attempt: The Declarative Semantics T>o 

4.1 Introduction 

We present the definition of a declarative semantics T>q, which is simple enough to 
illustrate the basic intuition behind our final declarative semantics T> but which is 
not completely satisfactory as it does not handle polymorphism (see Section^J . 
The declarative semantics T>q is defined for abstract programs written according 
to the abstract syntax AS, summarized in Figure^ Correctly typed Mercury pro- 
grams can be translated into 45 as a by-product of the type inference algorithm 
presented in Q. Nevertheless, the fact that the program is correctly typed is not 
essential to the definition of T>q, which is an untyped semantics. Note however, 
that, we assume, in abstract syntax AS, that there is no incomplete (identifier or 
term) call or application. An identifier call (or application) is incomplete if the 
arity of that identifier is strictly greater then the number of arguments supplied 
in that call. Incomplete calls and applications are replaced by explicit predicate 
and function terms, respectively, by the type inference algorithm given in Q. 
TableOdescribes the syntactic domain for AS. The arity of every constructor, 
type constructor, and identifier is given by a G (C U Tc U Id) ^ IN. 



Symbols 


Descriptions 


vev 


Variables 


ce c 


Constructors 


id € Id 


Identifiers 


tv € Tv 


Type Variables 


tc G Tc 


Type Constructors 


pid G Pid 


Program Identifiers 


te G Te 


Terms 


g&G 


Goals 


ty e Ty 


Types 


tydef G Tydef Type Definitions 


fdef G Fdef 


Function Definitions 


pdef G Pdef 


Predicate Definitions 


prog G Prog 


Programs 



Table 1. Symbols used in AS 
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te 


-.= V \ c te* 1 pred v* g \ func v* 
apply id te* \ apply te te* 


V g 1 


g 


true j fail | unif te te | 
call id te* \ call te te* \ 
not £/ 1 £/ and £/ 1 £/ or 5 1 






if g then g else g \ exists v 


* g 


ty 


:= tv 1 tc ty* 1 pred ty* \ func ty 


* ty 


tydef 


:= tc tv* (c ty*)* 




pdef 


:= id (pred ty*) v* g 




fdef 


:= id (func ty* ty) v* v g 




prog 


— pid tydef* pdef* fdef* 





Fig. 2. Abstract Syntax AS. 



We assume that sum/1 is a function taking a list of integers and returning 
the sum of the integers in that list. The application of Deville’s Methodology for 
Mercury to sum/1 is straightforward and we do not present it for space reasons. 

We will illustrate Vq through the abstract program Pas corresponding to 
the Mercury program P composed by the Mercury code for map/3 given at the 
end of Section ^Hand predicate: 

pred goal. 

goal : - map (sum, [[1] , [1,2] , [1,2,3]] , [1,3,6]) . 

The abstract program Pas is: 
list(T) ([] , [Tllist(T)]) 

goal predO calKmap, (func(Al)=A2 unit (A2 , apply (sum, (Al) )) , 

[[1] , [1,2] , [1,2,3]] , [1,3,6])) 

map pred(func(Tl)=T2,list(Tl) ,list(T2)) (F,L1,L2) 

(exists [XI , X2 , L3 ,L4] ( (unif (LI , [] ) and unif(L2,[])) or 

((unif (LI, [X1IL3]) and unif (L2 , [X2 I L4] ) ) 
and 

(unif (X2 , apply (F, (XI) ) ) and calKmap, (F,L3,L4)))) ) ) 
It is worthwhile to note that, in Pas'- 

1. the type of every predicate (function) is contained in the definition of the 
predicate (function) itself; 

2. every predicate call is explicitly indicated by call; 

3. every function application is explicitly indicated by apply; 



28 



Dante Baldan, Baudouin Le Charlier, Christophe Leclere, and Isabelle Pollet 



4. every occurrence of a function (predicate) identifier as argument is replaced 
by a function (predicate) term containing an application (call) of that iden- 
tifier. 

5. every variable is either in the head of a predicate (or function) definition or 
explicitly existentially quantified. 

An example of premisejis given by the term f unc (Al) =A2 : - unif (A2 , apply 
(sum, (Al) ) ) replacing the occurrence of sum/1 as argument of map/3 within 
predicate goal/0. We introduced the transformation indicated at point J to 
avoid having identifiers as terms both to give a simpler declarative semantics 
and to stress that identifiers are not terms. Abstract programs are admittedly 
harder to parse than corresponding Mercury codes. Nevertheless, we (classically) 
use the abstract syntax AS to present the semantics, since AS exhibits the “deep” 
syntactic structure of the language (e.g., it is explicit and non ambiguous). 

The rest of the section is organized as follows. Section ^3 illustrates the 
universe of values U. Section^Jgives the denotation of terms and goals in Vq, 
whereas the denotation of types is given in Section^3 Section^3presents the 
semantics T)o whose limits are given in Section ^3 



4.2 The Universe of Values U 

We propose a unique domain of values U rather than defining a domain based 
on the syntactical objects of an abstract program. Our choice follows Deville’s 
methodology for Prolog in which the declarative semantics is based on a unique 
universe of Herbrand obtained from a priori fixed sets of constants and functors. 
The universe of values U is based on an infinite set C of constructors, fixed once 
and for all. We assume that integers (and other basic built-in types of Mercury) 
are contained in C as constructors of arity zero. 

Since we want to use the declarative semantics T>o to support Deville’s 
methodology for Mercury, we think that the universe of values U should contain 
“true” functions and predicates defined as sets of pairs (in a “naive” set-theoretic 
sense) rather than lambda terms. We claim, indeed, that “true” functions and 
predicates are close to the way a programmer reasons about functions and pred- 
icates in writing Mercury programs. Since functions and predicates are higher 
order objects, we define a hierarchy to represent them. Informally speaking, the 
universe of values U is the top of a hierarchy whose bottom level contains all 
ground terms in the logic programming sense, level 1 contains functions and 
predicates over bottom level, level 2 contains functions and predicates over level 
1, and so on. Also, Mercury terms composed of a constructor whose arguments 
contain function or predicate terms, are mapped to values in U composed by that 
constructor having “true” functions and predicates as arguments. It is worth- 
while to note that our definition of C7 as a hierarchy forbids the consideration of 
recursive domains D such as, e.g., D = A + {D ^ D) . We take the position that 
such domains D are lacking an intuitive semantics and that they are unpractical 
for program construction reasoning. Moreover, our declarative semantics is not 
aimed to model non termination, and, hence, we follow the usual first order logic 
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approach in the definition of interpretations of formulas by including only total 
functions in our domain of values. We illustrate the elements in U using integers 
and constructors occurring in Pas ({ D /0> -/2}) and then we give the formal 
definition of U. 

The first level in the hierarchy is indicated by C/q and it is the usual Herbrand 
universe of first order logic. More precisely, C/q is the set of all first order ground 

terms constructed using the list constructor ./2 and constants [],0,±1,±2, 

Examples of elements in Uq are: [], 0, ±1, ±2,..., [0], [1], [—1], [2], [—2], ..., 

[0, 0|0], [0, 1|0], [0, — 1|0], [0, 2|0], [0, — 2|0], Notice that no type constraint is 

imposed on terms, and, thus, in addition to nil-terminated lists, there are also 
ill-formed lists. 

The second level in the hierarchy of sets defining U is occupied by U\ which 
is defined as follows. Let C/q be the union of C/q and the sets containing: 

— all functions whose domain is the Cartesian product of subsets of Uq and 
whose codomain is a subset of Uq. For example, Uq contains Sum : List{1.) — > 
Z, which takes a list of integers and returns the sum of the integers in the 
list, and Plus : Z x Z — > Z, which is the usual arithmetic summation; 

— all predicates whose domain is the Cartesian product of subsets of C/q. For 
example, Uq contains Collinearn ■ Listn{^) x Listn{^) Bool, testing 
whether for every pair ([a;i, . . . , a;„], [j/i, . . . , y„]) of lists of integers there 
exist two integers r and s such that Xi*r = s * yi, for i = 1, . . . , n. 

Ui is the smallest set containing Uq and all objects composed of a construc- 
tor whose arguments are elements of U\. For example, U\ contains [Sum] and 
[Collinearn]^] - It is worthwhile to note that U\ includes lists containing functions 
and/or predicates. We think that such values are the natural interpretation of 
lists containing higher-order terms which represent functions and/or predicates. 
Ui {i > 1) is defined similarly. The universe of values U is the union of all such 
sets. 

Definition 1. Let C be the set of all constructors. The domain of values, called 
universe U , is the union of the sets in the increasing chain Uq C U\, . . . defined 
as follows. 

Uq is the set of the first order ground terms constructed using all constructors 
in C. For every i >0, let: 

1. Funci = {{Di X ... X Dn) ^ D : n G \N, Di , . . . , D„, D G p{Ui)}; 

2. Predi = {{Di x . . . x Dn) Bool : n G IN, Di , . . . , Dn G p{Ui)}; 

3. C/' = C/j U FunCi U Predt. 

Ui+i is the smallest set containing U[ and such that: Vc G C,d\, . . da(c) G Ui+i 
it holds that c{di , . . . , da(c)) G Ui+i. The universe of values U is: 

OO 

u = \ju, 

z=0 
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We remark that the domains of functions (and predicates) in U are “(hyper)- 
rectangles”, i.e., the Cartesian product of subsets of U. We think that such a 
choice is consistent with the denotation of the type of a function term in AS. For 
instance, if te is a function term in AS with two arguments whose types are both 
int, then the denotation of te is a function / whose domain is Z x Z. Clearly, 
if we are interested only on the values of / on a subset A of Z x Z, then / is 
not uniquely determined because any other function whose domain is Z x Z and 
equal to / on A is well-suited to be the denotation of te. We will use the axiom 
of choice to select any of such denotations in the semantics of function terms. 

The following functions and V formalizes the notion of function and pred- 
icate application in the universe U . When a function or a predicate is applied to 
a value outside its domain, we report a special value named error. 

J- : U X U* ^ U U { error} V : U x U* ^ Bool U { error} 

( f{d*) if f is a function and d* € dom{f) 

y error otherwise 

{ p{d*) if p is a predicate and d* G dom{p) 

error otherwise 

For the sake of simplicity, in the following we write f{d*) and p{d*) in place of 
T{f,d*) and V{p,d*), respectively. 

4.3 The Denotation of Terms and Goals in X>o 

In order to define the denotations of goals and terms T>o, we introduce some 
preliminary concepts. We define the notion of admissible sets that are subsets 
of U contained in Ui for some i G IN. We will consider only functions and predi- 
cates whose domain and codomain consist of admissible sets. This restriction is 
necessary to ensure that the denotation of every term belongs to U. 

Definition 2. A subset D of U is admissible if and only if there exists i G IN 
such that D C Ui, where Ui, i = 1, ... is the sequence of sets defining U (see 
De/H. The set of admissible sets is denoted by A{U). 

The denotation in Vq of terms and goals is obtained through the values asso- 
ciated with variables and identifiers. More precisely, every variable and identifier 
is associated with a value in U and with a domain, i.e., an admissible set, rep- 
resenting a set of possible values for that variable or identifier. The denotation 
of a term te (goal g) can be either a value in U (Bool) or error if the value of a 
subterm is found incompatible with its domain during the evaluation of te. The 
following definition formalizes the previous intuition. 

Definition 3. An Identifier Environment is a function in lenv = Id ^ {7 and l 
indicates an identifier environment. A Set Environment is a function in Senv = 
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(VUldUC) — > A{U) and e indicates a set environment. A Variable Environment 
is a function in Venv — 'V —>■ U and v indicates a variable environment. 



a set environment, an identifier environment, and a variable environment. In 
the definition of V, e and t are “hidden” arguments, i.e., they are not explicitly 
indicated in the left hand side of any of the equations for V. Hidden arguments 
are specified by enclosing their domains into brackets in the signature of the 
semantic function. We adopted that convention for having a light notation and 
for concentrating the attention of the reader on the most relevant parts of the 
definition of V: hidden arguments are never modified in the right hand side of 
the definitions; so, they can be thought as “global”. Any occurrence of e and l 
in the right hand side of an equation is to be interpreted as a reference to the 
corresponding hidden argument of V. We assume that error propagates through 
the evaluation of all rules. 

Definition 4 (Denotation of Terms). The denotation of terms is defined by 
induction on the definition of terms in AS: 



Using Definitions H^^ndH the denotation of a term V is obtained through 



V : Te — > [Senv] — > [lenv] — > Venv —> U U { error} 





error otherwise 




V|c te*jv = c{V\te*\v) 



Xd* e e|?;*] . gig\v[v*/d*\ if^d* G e|u*] : 



V|pred v* = < 



^ error 



error 



otherwise 




choice(S') ifSf^% 



otherwise 



V|apply id te*}^ 





otherwise 



V|apply te te*p = {Vltep){Vlte*p) 



where S = {f £ D* ^ D : ^d* £ D* : gigP[v* /d* ,v/ f{d*)] = TRUE], choice 
indicates “any function” (axiom of choice), D* = and D = e\v\. 
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As for V, e and l are “hidden” arguments also in the denotation of goals Q. 
We assume that error propagates through the evaluation of all rules. 

Definition 5 (Denotation of Goals). The denotation of goals is given by 
induction on the definition of goals in AS: 

Q : G ^ [Senv] — > [lenv] — > Venv — > Bool U { error} 

^|true]i^= TRUE 

0|fail]i^ = FALSE 

tj|unif tei te 2 \v = (V|tei]i^ = V|te 2 ]i^) 

f {i'lidl){Vlte*lv) if L\idl e e|zd] 

5|call id = < 

[ error otherwise 

0|call te te*Jiy = (V|te]i^)(V|te*]i^) 

0|not gjiy = ^{Glgjty) 

Glgi and52li^= {Glgip A Glg2lv) 

Glgi or g 2 p = (Glgipu Glg 2 lv) 

error if 3d* € e|u*] : = error 

TRUE ifVd* e e|u*l : Glgp[v* /d*] error 
^[exists u* g\v = and 

3d* G e|u*l : GlgMv*/d*\ = TRUE 

^ FALSE if\/d* G e|u*l : Glgp[v*/d*] = FALSE 
error if Glgi}:^ = error 

^|if 5 i then 52 else 53 ]i/ = < Glg 2 ji' if Glgijv = TRUE 

^Glg3p if GlgiP = FALSE 




A Step Towards a Methodology for Mercury Program Construction 



33 



4.4 The Denotation of Types 

It is worthwhile to note that no reference to types has been taken into account 
up to now nor in the denotation of terms (Definition^ nor in the denotation of 
goals (Definition^. This allows us to incorporate the denotation of types into 
the declarative semantics as a distinguished choice of admissible sets, stressing 
that types are just used for avoiding that error be the denotation of terms and 
goals. 

The denotation of a type ty is obtained by associating every type variable 
in ty with an admissible set and every type constructor tc in ty with an admis- 
sible set obtained through the type definition for tc. In order to formalize that 
intuition, we introduce the following definition. 

Definition 6. A Domain Environment is a function in Denv = Tv ^ A{U) 
and S indicates a domain environment. A Type Constructor Environment is a 
function in Tcenv = Tc — > Denv — > A{U) and 7 indicates a type constructor 
environment. Finally, tvarlist G Tc ^ Tv* is a function associating every type 
constructor tc with a list tv* of distinct type variables such that a{id) = \tv*\. 

Every type is evaluated by extending every domain environment, i.e., every 
denotation of type variables. We remark that 7 is a “hidden” argument. For the 
sake of simplicity, we assume that every Mercury primitive type, such as int, 
are evaluated into their “natural” set of values. For example, int is evaluated, 
by definition, into Z. 

Definition 7 (Denotation of Types). The denotation of types is given by 
induction on the definition of types in AS. 

T : Ty ^ Denv [Tcenv] ^ A{U) 

Tltv\5 = T\tc ty*\5 = y{tcl{5[tv* / D*\) 

T|func ty* ty\5 = {D* D) T|pred ty*\5 = {D* — > Bool) 
where tv* = tvarlist{tc) , D* = T|t?/*](5, and D = T|ty](5. 

4.5 Models of Type Correct Programs 

In order to take into account Mercury primitive functions (predicates) such as 
integer addition, we can assume that every t G lenv and e G Senv provide the 
semantics of these operations (predicates) without requiring the existence of a 
corresponding definition in the program. 

A type correct program defines a type constructor environment through a fix- 
point computation Q. For example, list /I is associated with all nil-terminated 
lists composed by elements of admissible sets. Also, given a domain environment 
(5, a type correct program defines a set environment which is obtained through 
the types of identifiers and the type definitions provided by that program. 

tFo : Prog Denv — > Senv lFo|P](5 = e 
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where for all v and id in P: 

eH = TftyyjSj efidj = TltyidjS-f 

where ty^ and tyid are the types of v and id, respectively, and 7 is the type 
constructor environment associated with P. The type of identifiers in a type 
correct program P is provided directly by P whereas the type of variables in 
P is provided by the type inference algorithm ^ applied to P. We are now in 
position to define the models of type correct programs. 

Definition 8 . Let P be a type correct program and 7 S Tcenv be the type 
constructor environment defined by that program. A model of P in T>o is l G lenv 
such that for every 6 € Denv and v G Venv.' 

1. For every predicate definition (id (pred ty*) v* g) in P: 

€ e|zd] = D* — *■ Bool and Vd* G D* : = Qlgjei ^[ 0 * / d*] 

where D* = T|ty *](57 and e = lFo|P]5; 

2. For every function definition {id (func ty* ty) v* v g) in P: 

4idj G elidj = D* ^ D and \/d* G D* : gigjeciy[v*/d*,v/f{d*)] = TRUE 

where D* = Tlty*lSj, D = T|fy]( 57 , / = i\id\, and e = lFo|P](5. 

We remark that the quantification over v in Definition^ is purely technical 
since v* and v are the only free variables occurring in g (cf. B). 

4.6 A Sample Model in T>o of Pas 
Let t G lenv be defined as follows: 

— 4goal/0l = TRUE; 

— t|map/3] = map G {{List{1.) ^ Z) x {List {List {'K))) x {List{1.))) —> Bool, 
where, 'd{f,[xi, . . . ,Xn],[yi, ■ ■ ■ ,ym]) G {List{Z) ^ Z) x {List{List{Z))) x 
{List{1-))-. 

f Kl^fiVk = f{xk)) ifm = n 
map{f, [xi, . . .,Xn], [yi, ■ ■ -,ym]) = < 

[ FALSE otherwise 

— t|sum/l] = sum G List{1.) Z, where, V[z/i, . . . , z/m] G List{1.)\ 

m 

sum{[yi, . . . ,ym]) ^'^yi 

i=l 

It is easy to verify 0 that t is a model in T>o of Pas- In the definition of 
L, we exploit that there is only one call of map/3 with instantiated arguments. 
Consider, in fact, the abstract program P'j^g obtained from Pas by adding to the 
body of goal/0 the predicate call map (reverse, [[1] , [1,2] , [1,2,3]] , [[1] , 
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[2,1] , [3,2,1]]), where the function reverse/1 takes a list and reverses it. 
P'j^g contains two different calls to map/3 with two different functions as first 
argument. Clearly, we cannot define an identifier environment as before, because 
we have to take into account two possible instances of map/3, i.e., we have to 
handle polymorphism of identifiers. The solution proposed in our declarative 
semantics V is that every instance of the type of identifiers is associated with 
a different predicate (or function) in U . This will be done in Section by 
modifying the definitions of identifier environments and set environments. It 
would be also possible handling polymorphism by associating every predicate 
(function) identifier with a unique predicate (function) in U , whose domain is 
“large” enough to contain all possible instances of the type of that identifier. 
This would mean handling polymorphism by assuming that every function has 
only one (“big”) type, but we think that this is too far from the intuition of a 
programmer about types. 



5 Declarative Semantics T> 

We present our declarative semantics T> which is able to express the polymor- 
phism of identifiers. T> has the same universe U of values as T>o and the evaluation 
T of types does not change. There are two differences between T> and Vq-. (1) 
set environments of T>q are replaced by set environments for identifiers and con- 
structors, and by set environments for variables in T>, (2) identifier environments 
in I?o are redefined in T> in order to handle the polymorphism of identifiers. 

This section is organized as follows. Section presents the denotations of 
terms and goals in T>. Section defines T> and Section illustrates a model 
in T> of P'as- 



5.1 The Denotation of Terms and Goals 

As anticipated at the end of Section^J T> is obtained from Up by introducing 
new definitions of identifier environments and set environments. An identifier 
environment, in T>, expresses the polymorphism of identifiers by associating ev- 
ery identifier with a (partial) function whose domain is the set of all tuples of 
admissible sets and whose codomain is U . For simplicity, we extend such partial 
functions to total functions by associating error with every value outside their 
original domain. Using the new definition of identifier environment, we overcome 
the problem encountered at the end of Section^J because every function (pred- 
icate) identifier is associated with a family of functions (predicates) in U and 
not with a single function (predicate) as in T>q. 

Set environments for constructors and identifiers express the polymorphism 
of constructors and identifiers by associating every constructor and identifier 
with a (partial) function whose domain is the set of tuples of admissible sets 
and whose codomain is A{U). As for identifier environments, we extend such 
partial functions to total functions by associating error with every value outside 
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their original domain. As for T>o, set environments for constructors and identi- 
fiers allow us to define T> as an untyped semantics, i.e., a semantics where the 
denotation of types is not needed in the denotation of terms and goals. 

A set environment for variables, in T>, is a set environment of T>o restricted 
to variables, i.e., it associates every variable with an admissible set. Finally, as 
in T>o, every variable is associated with a value in {7 by a variable environment. 

Definition 9. An Identifier Environment is a function in lenv = Id ^ A{U)* 
^ U U {error} and l indicates an identifier environment. A Set Environment 
for Constructors and Identifiers is a function in ISenv = (C Uid) ^ A{U)* 
A{U) U {error} and Ci indicates a set environment for constructors and identi- 
fiers. A Set Environment for Variables is a function in VSenv = V — > A(U) 
and €y indicates a set environment for variables. A Variable Environment is a 
function in Venv — 'V^U and v indicates a variable environment. 

We present the denotations of terms and goals in T> and we introduce an 
auxiliary function A that computes the domain of a term. A is used to compute 
the tuples of admissible sets for the second argument of identifier environments 
and set environments for identifiers, and thus, it was not needed in Vq because 
identifier environments and set environments in T>o do not have such an input 
argument. 

Every term is associated by A with an admissible set depending on the 
admissible sets associated with the variables occurring in that term. The value 
of A is either an admissible set or error. We can have error in the evaluation of 
a predicate or function term if the corresponding goal contains a term which is 
recursively associated with error. The bottom case for having error is when the 
domain of a function term is not compatible with the type of its argument. We 
also assume that error propagates through domain evaluation. We remark that, 
in the definition of A, both Cj and e„ are considered “hidden” arguments. 

Definition 10 (Domain of Terms). The domain of terms is defined by in- 
duction on the definition of terms in AS. 

A : Te [ISenv] — > [VSenv] ^ A(U) U {error} 



Z\|cte*l = (ei|c])(Z\|te*l) 

ifVte in g : A|te] yf error 
otherwise 

if'ite in g : A|fe] yf error 
otherwise 



Z\|predu* 5 ] = 
Z\|func u* u g] = 



(e„|u*| ^ Bool) 
error 

^ e„|u] 
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Z\|apply fd te*j = (ei|zd])(Z\|ie*]) 



D if ^|ie] = D* ^ D ^ error and 



Z\|apply te te*\ = < 



Z\|ie*] = D* does not contain error 



error otherwise 

\ 



The denotation of a term is obtained through a set environment for construc- 
tors and identifiers, a set environment for variables, an identifier environment, 
and a variable environment. We remark that, in Definition ei, e^, and t 
are “hidden” arguments. With respect to Definition^ we replaced Senv with 
ISenv and VSenv. We give in Definition ^Jonly the case of identifier appli- 
cation because, thanks to “hidden” arguments, all other cases are the same as 
in Definition^ We assume that error propagates through the evaluation of all 
rules. 



Definition 11 (Denotation of Terms). The denotation of terms is the fol- 
lowing: 



V : Te ^ [ISenv] ^ [VSenv] ^ [lenv] — > Venv — > t/ U { error} 



where 

V|apply id te*p = ((t|id])(Z\|te*]))(V|fe*]i^) 

The denotation of a goal is obtained, as for terms, through a set environment 
for identifiers, a set environment for variables, an identifier environment and a 
variable environment. As in Definition^] e^, e^, and t are “hidden” arguments. 
With respect to Definition^ we replaced Senv with ISenv and VSenv. We 
give in Definition^Jonly the case of identifier call because, thanks to “hidden” 
arguments, all other cases are the same as in Definition H We assume error 
propagates through the evaluation of all rules. 

Definition 12 (Denotation of Goals). The denotation of goals is given by 
induction on the definition of goal in AS. 

Q : G ^ [ISenv] ^ [VSenv] ^ [lenv] ^ Venv — !■ Bool U { error} 

C/|call id te*jv = ((4tdl)(^[te*]))(V|te*]i/) 



5.2 Models of Type Correct Programs 

We recall that a type correct program defines a type constructor environment 
through a fixpoint computation Q. A type correct program defines a set envi- 
ronment for constructors and identifiers which is obtained through the types of 
identifiers and the type definitions provided by that program. Also, every pair 
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composed by a domain environment and a type constructor environment defines 
a set environment for variables. With respect to Vq, Tq is split into T\ and 
according to the splitting of Senv into ISenv and VSenv. Let 7 be the type 
constructor environment defined by P . We have: 

Ty : Prog ^ ISenv Ty [P] = Ci 

where: 

— for all function definitions {id (func ty* ty) v* v g) in P\ 

dom{ei\id\) = {T\ty*J6'y : 5 G Denv} 

V(5 G Denv : eilidl{T{ty*l5"f) = {T{ty*l5-t) (Tpyl^y) 

— for all predicate definitions {id (pred ty*) v* g) in P: 

dom{eilidl) = {Tlty*}Sj : 6 G Denv} 

WD* G dom{eilidl) : ei|i(i]D* = D* -i- Bool 

— for all type definitions tc{tv*) (. . . , c{ty*), . . .) in P: 

dom(ei|c|) = {Tlty*lS'y : S G Denv} 



V(5 G Denv : ei|c](T|t?/*](5) = 7|te](5 

Also, we have: 

: Prog ^ Denv ^ VSenv 1F2|P](5 = 
where for all v in P\ 

= Tlty\5"t 

where ty is the type of v provided by the type inference algorithm | and 7 is 
the type constructor environment defined by P. We introduce the definition of 
model of a type correct program in T>. 

Definition 13. Let P be a type eorreet program and 7 G Tcenv be the type 
eonstruetor environment defined by that program. A model of P is l € lenv sueh 
that for every 6 G Denv and v G Venv.' 

1 . For every predieate definition {id (pred ty*) v* g) in P: 

Wd* G D* : { 4 idjD*)d* = gigj€i€yu^[v*/d*] 

where, D* = Tlty*jSj, = Pi|Pl, and e„ = p2\P\d; 

2 . For every function definition {id (func ty* ty) v* v g) in P: 

W* G D* : gigj€ieyLi^[v*/d*,v/f{d)] = TRUE 
where, D* = Tlty*lSj, f = ilidjD*, et = Pi|P], and Cy = 1F2|P1(5- 
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5.3 A Model of the Program 

We revisit the abstract program which is type correct, illustrating how our 
declarative semantics V overcomes the limits of T>o- It is easy to prove 0 that 
the identifier environment t defined as follows is a model of P'as- 

— t|goal/0]l7 = TRUE and WD* ^ fl : t|goal/0]Z3* = error; 

— (.|map/3]Z3* = mapj^, C D* Bool, where D* = ((-Di ^ D 2 )x{List{Di))x 
{List{D 2 ))), with Pi,P 2 G A{U), and V(/, [si, ...,Xn], [yi, ■ ■ - , y-m]) G D*: 

( ALi (s/fc = /(®fc)) ifm = n 

mapjy,{f, [xi, . . . ,x„], [yi , . . . = < 

I FALSE otherwise 



and VI?'* yf D* : t|map/3]I?'* = error] 

— (.|sum/l]Iyist(Z) = sum G {List (Z)) — > Z, where V[yi, . . . , ym] G List{1.)-. 

m 

sum{[yi, . . .,ym]) 

i=l 



and, VI?* List{1.) : t|sum/l]I?* = error] 

— (.|reverse/l]Lis<(Z) = reverse G List{1.) List{1.), and V[yi, . . . , G 
List{'^)\ 

reverse{[yi, . ..,ym]) = [Vm, • ■ • , yi] 
and, VI?* y^ List{1.) : t|reverse/l]I?* = error. 



6 Discussion 

The declarative semantics, which has just been defined, can be used to build logic 
descriptions ^ in Deville’s style, which is mainly based on structural induction 
and ensures — roughly speaking — that the user’s intended model is the unique 
model of the program; the novelty is that logical descriptions can now be higher- 
order. Further works will adapt SLDNF-resolution ^ to the context of Mercury 
to make it possible to prove that well typed and moded Mercury programs 
actually compute a set of answers covering the declarative semantics. 

In the context of schema guided synthesis of logic programs BB, we conjec- 
ture that it is natural to see the isoinitial models of open programs as denota- 
tions of polymorphic functions and procedures in Mercury. This would ensure 
that well-moded Mercury translations of correct open programs BQ are opera- 
tionally correct. 
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Abstract. Many of the systems which we, and those who have worked 
with us, have built were intended to make it easier for people with partic- 
ular backgrounds to construct and understand logic programs. A major 
issue when designing this sort of system is pragmatics: from the many 
logically equivalent ways of describing a program we must identify styles 
of description which make particular tasks easier to support. The first 
half of this paper describes three ways in which we have attempted to 
understand the pragmatics of particular domains using well known meth- 
ods from computational logic. These are: design using parameterisable 
components; synthesis by incremental addition of program slices; and 
meta-interpretation. These are helpful in structuring designs but do not 
necessarily provide guidance in design lifecycles - where less detailed 
designs are used to guide the description of more detailed designs. The 
second half of this paper summarises an example of this form of guidance. 



1 Why Domain Specific Systems are Needed 

This paper concerns the use of generic forms of design of logic programs in 
domain-specific applications. Much of the logic programming literature has a 
different concern: to construct systems which are as general as possible, and 
preferably independent of domain. The reason why we are interested in focussed 
systems is that the problems we tackle normally involve engineers who have 
neither the time nor inclination to learn deeply about logic (for example some 
of the systems described in Section^Jwere used by ecological modellers, while 
some of the systems described in Section^3were used by novice programmers) . 
They tend to be interested in preserving the styles of description which they 
already know and trust, so our uses of logic programming must mesh with these. 
However, we do not want to make our systems so domain-specific that we must 
invent a new style of design each time we tackle a new problem. This creates a 
tension between the desire for generic design methods and the need for lifecycles 
which are tailored to particular domains. 

In SectionHwe show how we have used generic methods from logic program- 
ming to underpin domain-specific design systems. In each of these sections we 
begin by summarising the method; then exemplify its use in applied projects; 
finally explaining those factors which limited the size of our applications. To 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 1999. 

(c) Springer-Verlag Berlin Heidelberg 1999 



42 



David Robertson and Jaume Agustf 



save space, we have anchored the discussion in simplified formal descriptions of 
the methods - used as an aid to explanation rather than a description of the full 
method. 

Some general themes recur in the different methods. We often use a high 
level language targeted at a particular engineering group. This appears as the 
problem description {<P) in Section and as the parameterisation conditions 
(•?■) of Section^3 We frequently supply a library of standard design patterns, 
such as the parameterisable components of Section or the program slices 
of Section Sometimes we can split the design lifecycle into different stages 
which are highly modular but which connect closely for later analysis, as in the 
meta-interpretation of Section^J 

In Section 5 we note a problem with the systems described in the earlier 
sections. The general themes associated with each method apply in a localised 
way to a particular stage of design. Although the use of logic as a standard 
language helps us to share information between the different methods it does 
not, in itself, describe the process of refinement which often takes place when 
we use a high-level design to guide the construction of a more detailed design. 
Our work on this problem is at an early stage so we use a formal example as a 
means of describing our current view of this problem. We introduce a method of 
refinement which uses generic set-based notation for high-level designs; refining 
these to task-specific definitions; then further refining these with domain-specific 
details. 

2 Pragmatics at Individual Stages of Design 

The purpose of this section is to summarise, in as succinct a style as possible, 
the notions of pragmatics which we have found effective in a number of applied 
projects. In describing how ideas from logic program underpin these applications 
we have left aside the discussion of the interfaces by which groups of engineers 
supply the necessary problem descriptions and 'P in Sections^Jand^H and 
satisfy selection conditions {Select, Best, Choose, Instantiated and Completed 
in Sections^Hand^H . Inventing these user interfaces has been a major issue in 
almost every system we have designed but space limitations prohibit a discussion 
of these issues here. Readers with an interest in the interfaces used should refer 
to the papers cited for each system. Unlike the underlying formal methods, the 
interfaces we build normally differ between domains of application because each 
new domain brings new assumptions about the way in which groups of engineers 
wish to communicate. 



2.1 Parameterisable Components 

We have used parameterisable components in situations where it was possible 
to predict standard patterns of program description on a fairly large scale {i.e. 
where many of the patterns comprise more than one predicate) and where vari- 
ation in use of these patterns can be controlled via parameters which can be 
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explained to the engineers in our target domain. Although generic notions of 
parameterisability exist within logic programming {e.g. and functional pro- 
gramming {e.g. [^) we use more specific forms of parameterisation adequate for 
our applications. Our method of designing such systems is as follows: 

— We identify basic features of the domain which engineers use in order to 
select and instantiate standard patterns. Using an interface tailored to the 
task, statements in this restricted language are supplied by those engineers. 
We call this a problem description and represent it below using the symbol, 
<P. 

— We build a library of parameterisable components, each of the form: 

component{N, C,D,P) 



where N is the name of the top-level predicate defined by the component and 
C is a set of conditions which must all be satisfied from the problem descrip- 
tion in order to instantiate the component. When instantiated, D is a set of 
clauses defining the program for N, and P is the set of subsidiary predicates 
which we require in order to supply us with an executable component. If the 
component is self-contained then P is empty. 

— We construct a system which selects and instantiates components accord- 
ing to the problem description supplied by engineers. We describe this, in 
its simplest form, using the predicate parameterise{P, 'P, D) which denotes 
that a program consisting of the set of clauses D for satisfying the predi- 
cates named in P can be constructed through parameterisation using the 
problem description, The predicate Select{P, N, Pr) selects from P the 
predicate named N to construct, leaving remaining names Pr - The predicate 
Best{S, K) chooses the most appropriate component, K, from the set, S of 
candidates. 



parameterise{{\ , <P, {}) 
parameterise{P, <P,DU Dr) 
Select{P, N, Pr) A 



Best{{{C ,D' ,P')\ 



f component{N, C, D, P") A 
I VG.G € G ^ h G 



parameterise{Pr U P„, Dr) 



},(G,P,P„)) A 



Our earliest use of this form of design was in constructing animal population 
models from problem descriptions couched in the terminology used by ecolo- 
gists (see B). An example of a component (simplified from Q) is determining 
whether two animals (A and B) are considered to be in proximity to each other 
at time point T. There are various standard ways of defining this but one way is 
by assuming that the physical area is divided into grid squares and each animal 
is assigned a square. By satisfying grid{G) and locations{L) we find out what 
is the appropriate grid and where the animals are initially located. This infor- 
mation, when added to the definition of proximity, gives us the program for the 
component. To complete the definition we need to know how the dynamics of 
change in location works so located_at is in the set of new predicates. 
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component{in_proximity, 



' grid{G), 1 
locations{L) j ’ 
in_proximity{A, B, T) ^ 
located_at{A, Li,T)/\ 
adjoining{Li , L 2 )A 
located jxt{B , L 2 ,T), 
in_proximity{A' , B' , T') 
located_at{A' , L',T')A 
located_at{B' , B, T')A 
not{A' = B') 
{located_at\) 



U G U L, 



Engineers using this sort of system control design only through the problem 
description - in other words, they have little or no control over the decisions 
taken by the Select and Best predicates introduced earlier. Such decisions often 
involve domain-specific knowledge so the size of problem which we can tackle 
by this means is limited by the amount of such knowledge which we can supply 
and maintain. Nevertheless, there exist practical applications which are small 
enough to be tractable but large enough to be worthwhile. For example: 

— The WWW site for our research group 

(URL http : //www. dai . ed. ac .uk/groups/ssp/ index .html), was built and 
is maintained by automatic generation from a problem description. It can be 
explained succinctly in terms of the abstract description above. The prob- 
lem description, <P, is given using a simple set of facts describing our research 
group. Each component{N, G, D, P) specifies part of the site by instantiat- 
ing D via conditions G derivable from The conditions in G can all be 
determined automatically in this very narrow application, and the range 
of possible components is sufficiently small that Select and Best can also 
be determined automatically. In other words, those altering the problem 
description don’t need to know how the specification is synthesised. The 
specification is converted automatically to HTML via the Pillow translator 
(currently available from http://www.clip.dia.fi.upm.es). 

— A prototype system for connecting safety shutdown logic to segments of codes 
of design practice is described in H. In this case, the problem description, 

is a set of formal descriptions of parts of the codes of practice. Each 
component{N^ G, D, P) defines a standard segment of the specification of 
the shutdown logic, where G relates D to The control over choice of 
component (via Select and Best) is under the control of designers. The 
design support system keeps track of how the codes of practice relate to the 
designers’ choices of components. 



2.2 Synthesis by Slices 

The idea of constructing predicates via a sequence of “slices” manifests itself 
in different forms in the logic programming community. We have been most 
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strongly influenced by the style of development called “techniques editing” , first 
explained in Q and later elaborated by others (for example Q) . Our method of 
designing these systems is as follows: 



— We identify the basic flows of control (often called “skeletons”) which our 
target group of engineers will want to use. Each of these is defined by a set 
of clauses which define a predicate P of arity, n. A set of parameterisation 
conditions, 'Ps, (applied similarly to those described in Section^J are used 
to instantiate appropriate variables in the clauses. 

r P(Ai,...,A„) 'I 

skeleton{Ps, % • >) 



— We define transformations (often called “techniques”) as shown below. Each 
transformation adds an argument, N , to P and may add additional goals to 
the body of each clause (transforming each C to C"). Each transformation 
requires the instantiation of a set of parameterisation conditions, Pf 



P(Ai,.. 


■ • ; -^n) ^ 


-Cl ] 


r P{Ai,. 












p(a;,.. 




-Cm) 


[ P{A [, . . 





These transformations normally do not alter the original flow of control of 
the predicate, thus making it easier subsequently to combine predicates. 

— We build an interface with which the target group of engineers can select a 
flow of control and progressively extend it. We summarise this process us- 
ing the predicate techniques{D) which succeeds if there is a definition, D, 
obtainable by techniques editing. The predicate Choose{Sf , F) chooses an 
appropriate flow of control, F, from the set of skeletons, Sf. Instantiate{P) 
instantiates the parameters of a skeleton or of a transformation. Next{St, T) 
chooses a transformation step appropriate to the current partial definition. 
C ompleted{D) denotes that we have applied sufficiently many transforma- 
tions to complete our definition. 

techniques{D) ^ Choose{{{P'g,D'J\skeleton{Pg,D'J},{Ps,Ds)) A 
Instantiate{Ps)A 
extend{Ds, D) 

extend{Ds,D) ^ Next{{{Pi, % P;}, (-Zt*, P„)) A 

Instantiate{Pt)A 
extend{Dn, D) 

extend{D, D) ^ Completed{D) 
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This approach is most often applied to small-scale design of predicates, using 
a small library of highly adaptable skeletons and techniques. An example of a 
skeleton in such a library might be a definition of list traversal, where the param- 
eterisation conditions predicate _name{P) and n_cases{N) supply the predicate 
name and number of recursive cases. Each T is a test which is later supplied by 
the user of the program and is used to differentiate the recursive cases of the 
skeleton. 



rP([i?i|Ti]) Ti AP(Ti) 'I 

skeleton{{vredicatejaameiP),nj:ases{N)\, I ■ >) 

P{[Hn\Tn\) ^ T^AP{Tn) 

U(D) J 

A difficulty with using skeletons and techniques at this scale is that the 
decisions which users must make (both in selecting and parameterising the com- 
ponents) are both numerous and detailed. In the example above we must know 
we want to base our program on list traversal in order to choose the skeleton 
and, once chosen, we must be able to say how many recursive cases we need. In 
some cases it can be desirable to make such decisions explicit. For example: 

— In our use of techniques editing in supporting novice Prolog programmers 
I we worked at a fine level of detail but limited the diversity of the library 
used by novices so that the range of decisions they had to make was still 
small. The parameterisation conditions for skeletons, 'Pg, are established via 
simple questions such as the number of cases in a traversal skeleton. The 
parameterisation conditions for techniques, Pt, is similarly direct. At any 
point in design, the choice of Next step is from a small repertoire and the 
decision of when the design is Completed can be determined with respect to 
whatever example the novice programmer chose to tackle. 

— A more diverse library is contained in the techniques editing tool of the LSS 
system. We have used this for more sizeable designs - the largest being a 
reconstruction of the tool itself Q. However, this sort of system can only 
be used by engineers who are trained in the use of logic programming tech- 
niques because the questions which one must answer in satisfying P's and 
Pt can be sophisticated (such as the precise form of term deconstruction). 
The choice of Next step, although from a fixed set of options each time, 
also demands Prolog expertise. Only designers can tell when the design is 
Completed because it is always possible to add more slices to a predicate. 

— In more recent work, Castro has applied techniques editing to a narrow 
domain of application (the synthesis of animal population dynamics models) . 
In his system the library of skeletons and techniques is domain-specific and P's 
and ptf are complex. To avoid the ecological modellers using his system from 
having to learn about parameterisation Castro used a problem description 
(similar in purpose to the one in Section^J to allow description of features 
in ecological terminology. These are then translated into the language needed 
for parameterisation. 
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2.3 Enhancement by Meta-Interpretation 

Sometimes when we have built programs we want to construct additional mech- 
anisms which don’t change the definitions of the original programs but give us 
new ways of using them. For example, we might want to relate the execution of 
a program to some form of commentary on what it is doing. A natural way of 
doing this in a logic programming style is through meta-interpretation. Different 
variants of this method of design exist but we have been most inffuenced by the 
ideas of layered meta-interpretation given in . This type of meta-interpreter 
tends to be problem-specific so the method is best explained by a simplified 
example. 

Suppose that we have a collection of equations of the form equationiVy, /, P), 
where Vy is a variable- value pair of the form value{X, V) (with X being the name 
of the output variable and V recording its value); I is the list of inputs needed 
by the equation; and P is the procedure relating inputs to output. For example: 

equation{value{x , X), [value{y, Y)],X isY + 10) 
equation{value{y, T), [], T = 5) 

We might write a simple interpreter for these equation definitions which 
solves for any variable-value pair by selecting an appropriate equation; solving 
its inputs recursively and calling the equation’s procedure. 



solve{Vy) ^ equation{Vy , I , P) A solve _inputs{I) A P 



solve_inputs{\Vy\T\) <— solve{Vy) A solve_inputs{T) 
solve_inputs{[]) 

We can use this program to find the values for variables, for example, solving 
the goal solve{value{x , A)) binds X to 15. 

We may later find that just solving the equations isn’t enough. We also want 
to retain certain contextual information related to our interpreter’s choice of 
variable- values. We use assertions of the form context{Vy, E) to denote that the 
variable-value pair Vy is endorsed by the set of contextual information E. For 
example: 



context{value{x, V), {ca;}) 
context{value{y, V), {cy}) 

We could adapt our original interpreter to propagate this contextual infor- 
mation by adding an extra “slice” to predicates solve and solvejinputs. For 
example, the program: 



e_solve{Vy , EiU Ey) ^ equation{Vy , I , P) A e_solveJnputs{I , Ei) A PA 
context (Vy, Ey) 
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e_solve_inputs{[Vv\T], EyU Er) ^ e_solve{Vy , Ey) A e_solve_inputs{T, Ey) 
e_solve_inputs{[], {}) 



will find both variable- values and endorsements by satisfying goals of such as 
e_solve{value{x, X),E), binding X to 15 and E to [cx, cy]. The problem in doing 
this is that the means of solving the equations and propagating endorsements 
ar now closely bound together in the same predicate definitions. An alternative 
way of achieving the same result without transforming the equation interpreter 
is to define the endorsement strategy as a meta interpreter which sits “on top 
of” the original equation interpreter. For example: 



endorsed{solve{Vy), EbU Ey) <— dause{solve{Vy) , B) A 

context{Vy , Ey) A 
endorsed{B, Eb) 

endorsed{{A A B), Ey U Eb) <— endorsed{A, Ea) A 

endorsed{B, Eb) 



endorsed{G, {}) ^ not{G = (A A B)) A 
is_builtJn{G) A 
G 



endorsed{G, E) not{G = solve{Vy) V isjbuilt_in{G)) A 
dause{G, B) A 
endorsed{B, E). 



Using this interpreter we can obtain the same endorsements as before by 
giving goals such as endorsed{solve{value{x, A)), E). However, we have a much 
looser connection between the equation solving and endorsement strategies, so 
we could alter either (within limits) without having to change the other. We 
don’t have this flexibility in the e_solve definition. 

We have applied this sort of design strategy in reconstructing simulation 
models which were originally implemented in a System Dynamics notation (a 
standard process engineering paradigm in which state variables are thought of 
as “tanks” with “flows” of substance between them being controlled by systems 
of equations) . The largest of these is the BIONTE model of key vegetation pro- 
duction processes in the Amazon. Its Carbon and Nitrogen sub-models contain 
a total of 210 variables, of which 60 are parameters. Each of these parameters 
(and the equations connecting them to the 14 state variables) were obtained 
from different combinations of field data, physiological measurement and litera- 
ture survey. Hence the context of the model is highly heterogeneous. Brilhante 
B reconstructed the BIONTE Carbon and Nitrogen sub-models using meta- 
interpretation to reproduce the equation solving strategy for simulation and 
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confirmed that it produced results which closely matched the original modej 
We then extended the meta-interpreter to propagate contextual information, 
which could then be used to assess the heterogeneity of the data supporting pre- 
dictions given by the model. The original extensions to the interpreter were by 
normal extension (like in e_solve above) but we later used a layered approach. 

The main difficulty in this style of design is its flexibility. The point of meta- 
interpretation is normally to express some sort of explicit problem solving strat- 
egy and these vary depending on the problem in hand. Although it is possible to 
imagine sets of parameterisable components or techniques (in the style described 
earlier) for building meta-interpretation strategies, we are not aware of this be- 
ing done in practice. Until it is, we lack the empirical evidence to determine 
whether useful notions of standard practice exist at this level of description. 

3 The Need for Integration Across Lifecycles 

The uses of transformation described in the previous sections are diverse in their 
application while also being based on comparatively straightforward, abstract 
principles. However, there remains a major practical obstacle to their use on 
a larger scale: they are not integrated within any commonly accepted design 
lifecycle. Each of our synthesis systems is targeted at a particular aspect of 
design but we have looked less closely at the pragmatics of connecting design 
stages. However, it is the ability to establish such connections which makes 
large-scale formal design possible. In the remainder of this paper we describe 
some of our most recent work which is beginning to address this problem, and 
is complementary to the methods described earlier. 

In this section we introduce a method for describing generic inference strate- 
gies at a very high level and refining these to task-specific inference strategies. 
Central to our method is the idea that any inference strategy can be described 
as a logic program which takes as arguments sets of Horn clauses. We call each 
of those sets an axiom set. Inference is described by manipulating axiom sets. To 
give a flavour of what happens later, consider the definition below, which defines 
whether some axiom set, A2, follows from another axiom set, Ai. It does this 
by progressively expanding Ai, using some deduction mechanism, until it can 
be demonstrated capable of deducing everything in A2 . Its base case is when all 
the axioms in A2 are covered by those in Ai, while its recursive case enlarges 
Ai to a bigger axiom set, A3. 

f allow s{Ai, A2) ^ covered{Ai , A2) 

follows{Ai , A2) ^ enlarge{Ai , A3) A follows{As , A2) 

Given definitions for covered and enlarge, this describes a particular infer- 
ence strategy. However, we can describe it more generally by replacing specific 

^ This surprised us since our interpreter used simple differences between time points 
when applying equations, rather than the approximations to continuous change nor- 
mally used in System Dynamics modelling. 
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conditions by more general constraints between the axiom sets. In our example, 
the covered relation requires that everything which can consistently be deduced 
from A2 can also be deduced from Aij while the enlarge relation requires that 
the new set of axioms, A3, allows at least as much (and probably more) to be 
deduced from it than from Ai . In the formal notation which we describe below, 
this is expressed as: 



f allow s{Ai, A2) ^ i{Ai) D i{A2) 
f allow s{Ai, A2) ^ i{A\) C ^(^3) /\ follow s{A^, A2) 

In the remainder of this section we will describe (in Section the lan- 
guage we use to describe generic strategies like the one above; give refinement 
rules which allow these to be specialised to task-specific but domain-independent 
strategies (Section^3; introduce an example which demonstrates how this sort 
of refinement might work in practice (Section ^ 3 ; and finally show, for the 
example, how the addition of domain-specific refinements can produce an exe- 
cutable specification (Section^^. 



3.1 Language 

As the basis for our transformations, we define a language for describing axiom 
sets, their interpretations, and relations between them. These relations are of 
two kinds: generic relations which are understood purely in terms of set inequal- 
ities, and specialised relations which describe standard ways of satisfying these 
inequalities. The choice of language for the latter is a pragmatic one, reflective 
of our understanding of what should be “standard” . Therefore we make no claim 
that our choice is the ideal one. 

Definition 1 A restricted Horn clause is an expression of the form C ^ P , 
where C is a unit goal and P is either a single unit goal or a conjunction of unit 
goals, and denotes that conclusion, C , is true whenever precondition, P , is true. 
Negation is not allowed in the conclusion or precondition. 



Definition 2 The term a{S) denotes an axiom set, where S is either a variable 
or a set of restricted Horn clauses. 

Definition 3 The termi{S) denotes the interpretation of an axiom set, S. This 
is the set of all ground unit goals which can be deduced from S. 



Definition 4 (Extension) extended(A, E) denotes that a set of axioms, A 
can be extended to yield the set of axioms, E. This is true if E contains all the 
axioms of A plus some subset of all the axioms which can be deduced from the 
axioms in A. 
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Definitions (Axiom Constraint) constrained(A, Xi, X 2 ) denotes that ad- 
ditional constraints, consistent with axiom set A, have been added to the body of 
clause Xi to yield clause A2. For example, if X\ is of the form C <— Pi then 
X2 could 6e C <— Pi A P2 where P2 is an additional constraint which does not 
lead to an inconsistency with the other axioms in A. 

Definitions (Axiom Relaxation) relaxed(A, Xi, X 2 ) denotes that con- 
straints have been removed from the body of clause Xi to yield clause X2, in 
a way which is consistent with axiom set A. For example, if Xi is of the form 
C Pi A P2 then X2 could be C P\ where removing P2 does not lead to an 
inconsistency with the other axioms in A. 

Definition 7 (Specialisation) specialised) Ai, A 2 ) denotes that the axiom 
set Ai can be adapted to form an axiom set, A2, for which all ground goals 
deducible from A2 are deducible in A\ but some goals deducible from Ai may not 
be deducible in A2. 

Definition 8 (Generalisation) generalised(Ai, A 2 ) denotes that the axiom 
set Ai can be adapted to form an axiom set, A2, for which all ground goals 
deducible from Ai are deducible in A2 but some goals deducible from A2 may not 
be deducible in Ai. 

Definition 9 (Filtering) filtered(A, X) denotes that axiom X satisfies some 
test which is determined with respect to axiom set A. 

Definition 10 (Deletions) deletions(Ai, A 2 ) denotes that a subset, A2, of 
axiom set Ai can legitimately be deleted, according to some decision procedure 
defined with respect to Ai . 

Definition 11 (Addition) additions(Ai, A 2 ) denotes that the new axiom set, 
A2, consistent with axiom set A\, can legitimately be added to Ai. 

Definition 12 (Subset Generation) subseteq(A 2 , Ai) denotes that axiom 
set A2 is a subset derived from the axioms in A\ . 

3.2 Refinement Operations 

We now define a collection of transformation rules which relate generic set in- 
equalities between axiom sets and their interpretations to the specialised rela- 
tions from Section^H We have divided these into two groups: the first concerned 
with narrowing a set of axioms or its interpretation; the second widening a set of 
axioms or its interpretation. Each rule defines a rewrite from the set inequality 
(on the left of the arrow) to a more specific condition (on the right) which is 
consistent with the inequality. 
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Narrowing First we give the transformation rules for reducing the size of in- 
terpretations or axiom sets. RulesJtoHrelate set inequalities to our specialised 
relations. RulesHandHare based on general properties of sets. 

Refinement 1 The interpretation of axiom set A2 is narrower or equal to that 
of Ai if we can deductively extend A\ to give axiom set I\ and that set narrows 
to A2. 

i{Ai)Ai[A2) extended(Ai, Ii) A a(/i) D 0(^2) 

Refinement 2 The interpretation of axiom set A2 is narrower or equal to that 
of Ai if A2 is composed of constrained versions of some of the axioms of A\. This 
uses the predicate map_some{Si E2, S2) which is true if at least one (and 

possibly every) element E\ of set Si maps via the relation R to a corresponding 
element, E2 of S2 ■ 

i{Ai)Ai[A2) => map_some(Ai, Ai,constrained(Ai,Xi,X2), A2, A2) 

Refinement 3 The interpretation of axiom set A2 is narrower or equal to that 
of Ai if A2 is obtained from A\ by specialisation. 

i{Ai)Ai[A2) specialised(Ai, A2) 

Refinement 4 Axiom set A2 is contained in A\ if A2 is a subset formed from 
Ai- 

o(Ai) D 0(^2) ^ subseteq(A2, Ai) 

Refinement 5 Axiom set A2 is contained in A\ if A2 contains those axioms 
from Ai which pass some filtering test. This uses the predicate apply _some{Si , E\, 
T, S2) which is true if at least one (and possibly every) element E\ of set Si sat- 
isfies test T, with S2 being a set of all such elements. 

o(Ai) D 0(^2) ^ apply_some{Ai,Xi,fAteved{Ax,'Kx),A 2 ) 

Refinement 6 Either the axiom set or interpretation of A2 is narrower than 
or equal to the corresponding axiom set or interpretation of Ai (so T below must 
be i or a) if there are elements which can be deleted from Ai to form A2 . 

T{Ai) D T(A2) ^ deletions(Ai, A3) A remove(A3, Ai, A2) 

Refinement 7 The narrowing relation is transitive. 

Si A S2 => Si 2 S3 A S3 A S2 

Refinement 8 Set S2 is narrower than or equal to set Si if S2 is the union of 
sets S3 and S4 which are each narrower than Si . 



Si 2 S2 ^ Si 2 S3 A Si 2 S4 A union{S3, S4, S2) 
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Widening We now give the transformation rules for increasing the size of in- 
terpretations or axiom sets. These are duals of the ones we used for narrowing 
above, so ruleHbelow is a dual of rule Jabove, and so on. 

Refinement 9 The interpretation of axiom set A2 is wider or equal to that of 
Ai if we ean deduetively extend A\ to give axiom set I\ and that set widens to 

A2- 

i{Ai)Ci{A2) ^ extended(Ai, Ii) A a(/i) C 0(^2) 

Refinement 10 The interpretation of axiom set A2 is wider or equal to that of 
if A2 is composed of relaxed versions of all of the axioms of Ai. This uses 
the predicate map_all{Si, E\, R, i?2, S2) which is true if every element E\ of set 
S\ maps via the relation R to a corresponding element, E2 of 82- 

i{Ai)fli{A2) => map_a//(Ai, Ai, relaxed(Ai, Xi, X2), A2, A2) 

Refinement 11 The interpretation of axiom set A2 is wider or equal to that of 
^1 if ^2 is obtained from A\ by generalisation. 

i{Ai)ffi{A2) generalised(Ai, A2) 

Refinement 12 Axiom set A2 contains Ai if Ai is a subset formed from A2. 
o(Ai) C 0(^2) ^ subseteq(Ai, A2) 

Refinement 13 Axiom set A2 contains Ai if all axioms of Ai pass some filter- 
ing test which allows them to belong to A2. This uses the predicate apply jxll{Si, 
Ei,T,S 2) which is true if every element Ei of set Si satisfies test T, with 82 
being a set of all such elements. 

a{Ai) a{A2) ^ appZ?/_a/^(Ai, Ai,filtered(Ai,Xi), A2) 

Refinement 14 Either the axiom set or interpretation of A2 is wider than or 
equal to the corresponding axiom set or interpretation of Ai (so T below must 
be i or a) if there are elements which can be added to Ai to form A2 . 

T{Ai) C T{A2) additions(Ai, A3) A union{A^, Ai,A2) 

Refinement 15 The widening relation is transitive. 

Si C 82 => SiQ S3 A S3 C S2 

Refinement 16 Set S2 is wider than or equal to set Si if S2 is the intersection 
of sets S3 and S4 which are each wider than Si . 



5 i C ^2 ^ Si C S3 A Si C S4 A inter section{S3, S4, 82) 
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3.3 Domain- Specific Example 

From Section ^3 we have a language in which to describe generic inference 
strategies and Section gives us transformation rules with which we may re- 
fine these to specialised, task-specific definitions. But could this ever be useful 
in practice? We address this issue by taking an example from what is (arguably) 
the most commonly used informal design method in the knowledge-based sys- 
tems community: KADS (^3)’ The entire KADS method is complex and still 
evolving but a key element of it is a library of inference structure diagrams which 
often form the starting point for system design. We restrict our attention to one 
diagram from this part of the KADS method. 

Numerous KADS inference structures for classification tasks have been de- 
scribed. The diagram gives one form of classification in the KADS style. The 
boxes in the diagram are (roughly speaking) sources of knowledge on some 
topic while the ellipses are (roughly speaking) functions which relate knowledge 
sources. The idea is that we have some observations about the objects we wish 
to classify and some background theory which relates objects to classes through 
distinguishing features. Classification takes place by generating possible classes 
to which an object might belong; based on these classes, specifying attributes 
which may discriminate them; from these obtaining features for comparison; and 
matching these against the attributes of the objects which are known from our 
observations. Once this has been done sufficiently either to provide a close match 
or signal a mismatch, the inference mechanism produces an answer in the form 
of a truth value. 




The diagram above is informal because we cannot say precisely what the 
interpretation of its knowledge sources or functions should be. Two solutions to 
this problem have already been explored. The most common solution (and the 
one adopted in “mainstream” KADS) is to add a mixture of formal and informal 
information to say more about what the inference mechanism should do. This 
is useful but it doesn’t provide a formal route from early models (like the one 
above) to executable specifications. A second solution, explored by projects like 
ML^ (B, B)> is to attempt to give a formal semantics for the style of design 
used in KADS. The difficulty with this route is that the resultant formal system 
is complex (since the way KADS diagrams are interpreted in practice is complex) 
and therefore it is difficult to design lightweight systems of refinement for it. 
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A third solution, explored in this section, is to look within logic for notions 
of specification and requirement which do a job similar (but not necessarily 
equivalent) to the KADS inference structures; then relate these to the original 
KADS methods. We demonstrate this in the remainder of this section. 

First we must invent a generic way of describing classification tasks. One 
way of viewing this sort of task is that classification relates three key elements: 
the theory used in classification; the observations of a particular situation which 
are used to support classification; and the classification itself. Taking this view, 
we can define classification recursively. We have a classification when the theory 
allows it. If the theory does not allow it then we extend the theory by selecting 
appropriate observations and enlarging the theory as a consequence of the ad- 
ditional information. This view is expressed formally by the inference strategy 
below. 

We have a classification, C , based on a theory, T, and observations, O, if the 
interpretation of the theory includes that of the classification or if a subset. A, of 
the observations, O, when added to the theory gives some enlarged theory Tn from 
which we can produce a classification. Those observations added to the theory 
when extending it are removed from the set of observations to be considered. 



classified{T,0,C) <— i{T) A i(C) (1) 

classified(T, O, C) <— o(0) A o(A)A (2) 

union{A, T, Ti)A 
i{Ti) C i{Tn)A 
remove{A, O, 0„)A 
classified{Tn, On, C) 

We can refine this high-level definition of classification by applying the trans- 
formation rules from Section^3 For example, we can make the following trans- 
formations: 

— Applying refinement ^to the first condition of clauseHgives us the trans- 
formation: 



i{T) A i{C) => extended(T, Ii) A a{Ii) A a(C) 
the result of which we further refine using ruleHas follows: 

a(Ii) Q a(C) => apply_some(Ii, Xi,filtered(Ii,Xi),C) 
finally giving the new first condition of clause J as: 

extended(T, Ii) A apply _some(Ii, Xi,tiltered(Ii,Xi), C) 

— Applying refinement the first condition of clauseHgives us the trans- 
formation: 

a(0) D a{A) ^ a(0) ^ S3 A S3 A a{A) 
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then we refine the left hand side of the result (instantiating S3 to 0(^2)) 
with ruleH 

a( 0 ) D 0(^2) subseteq(A2, 0 ) 

and we refine the right hand side of the result with rule^ 

0(^2) D a(A) ^ appZ?/_some(A2, Ai, filtered(A2, Xi), A) 
finally giving the new first condition of clause H as: 

subseteq(A2, O) A apply_some{A2, Xi,Rltered{A2, Xi), A) 

— Applying refinement^Jto the third condition of clauseHgives us the trans- 
formation: 

i{Ti) C i(Tn) ^ additions(Ti, A3) A unzon(A3, Ti, T„) 

These refinements produce the more specific definition of classification given 
below: 



dassified{T, 0 ,C) ^ extended(T, Ii)A (3) 

apply_some{Ii, Xi,filtered{Ix, Xi), C) 

dassified{T, 0 ,C) ^ subseteq(A 2 , 0)A (4) 

apply_some{A2, Xi,filtered{A2, Xi), A)A 
union{A, T, Ti)A 
additions(Ti, A 3 )A 
union{A3, Ti, T„)A 
remove{A, O, 0„)A 
dassified{Tn , C) 

This definition is more specific than the one we started with, since it stipulates 
particular ways of narrowing or widening the axiom sets and interpretations. 
However, it makes no commitment to the domain in which we might apply this 
sort of classification. That is the focus of the next section. 

3.4 Domain- Specific Refinements 

At this point we have a description of classification which is task-specific (it 
describes a particular class of classification problems) but it is not domain- 
specific because we have not committed ourselves to the details necessary to 
apply it. To do this, we first describe the axioms which we expect to appear in 
the theory, observation and classification arguments (T, O and C in clauses | 
andHabove). For our example, suppose that these are as follows: 

— The theory axioms are either of the form 

dassifiable{C{X), [Ai , . . . , A„]) <— Ai(A), . . . , A„(A) (where C is a clas- 
sification for object X and each A is an attribute of it) or are of the form 
consequence{A{X)) ^ Ai{X), . . . , Am{X) (where A is an attribute of X 
considered to follow from knowing the other attributes Ai). 
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— The observational axioms are attribute definitions of the form A{X), where 

A is an attribute and X some object. 

— The classification will contain axioms of the form is_classified{C{X), \Ai, 

. . . , An]), where C is a classification for object X and each A is an attribute 

used to classify it. 

A typical goal which we would like to satisfy might be: 

dassified{[consequence{fast{X)) ^ red{X), 

dassifiable{sports_car{Ci), [fast]) <— fast{Ci), 
dassifiable(sports_car{C 2 ), [small, light]) <— small{C 2 ) A light{C 2 )], 
[red{car21), small{car21),light{car21)], 

Classes) 

and we would expect this to instantiate Classes to either 
[is_dassified{sports_car(car21), [/ast])] or 
[zs_c/assz/ze(i(sports_car(car21), [small, light])], 

depending on the choice of observations it includes in the classification. 

The task-specific template can be refined to produce this behaviour, pro- 
vided that designers in the domain have appropriate refinements available from 
a domain-specific library. To provide variety in design there should be a number 
of possible refinements available to the designer but, to keep our example short, 
we supply exactly those needed for this problem. These are refinements ^Jto^J 
below. 

Refinement 17 A form of extension from axiom set, A, to axiom set, E, is by 
forming a classification. 

extended(A, E) ^ form_classification{A,E) 

A classification is formed by finding the set of classes, C, which are classifi- 
able based on attribute set, S. 

form_classification{A, E) ^ 

setof{is_classified{C, S), satis fy{classifiable{C, S),A),E) 

A goal, C, is satisfiable from axiom set A if it appears in A or can be derived 
from A by satisfying the conditions of a clause; or if it is a conjunction and both 
parts can be satisfied from A. 



satis fy{C, A) ^ member{G, A) 
satis fy{C, A) member{{C <— P), A) A satis fy{P, A) 

satisfy{{Ci,C 2 ), A) ^ satisfy{Ci,A)Asatisfy{C 2 ,A) 

Refinement 18 A form of filtering of axiom X, given axiom set. A, is to show 
that X is the best classification known from A. 

filtered(A,X) ^ best_classification{A, X) 
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Wt define the best classification to be C\ with supporting attributes, S, if 
there is no other classification, C2, known from axioms A with a larger number 
of supporting attributes. 

best_classification{A, is_classified{Ci, 51)) <— 
length{Si, Li)A 

/ member{is_dassified{C2, 52), A)a\ 
not{C2 = C'i)A 
length{S2, L2)A 

L2 > Li J 

Refinement 19 A form of filtering of axiom X is to test whether it is an at- 
tribute definition. 



not 

V 



filtered(A,X) ^ is_attribute{X) 

Any object, X is allowed to have the attributes, red, light or small. 

is_attribute{red{X)) 

is_attribute{light{X)) 

is_attribute{small{X)) 



Refinement 20 A way of forming the subset, Ai, from set, A2, is by choosing 
any one of the elements of A2 as a single- element subset. 

subseteq(Ai, A2) ^ choose_one{Ai, A2) 

We have a single element subset of set A for any element of A. 

choose_one{\X], A) <— member{X, A) 



Refinement 21 Axiom set A2 is one which may be added to axiom set A\ if 
the axioms in A2 are considered consequences for classification in Ai . 

additions(Ai, A2) => consequences{Ai , A2) 

Consequences, A2, are those axioms, C , which satisfy the consequence defi- 
nitions in Ai . 

/A A \ r- 7 11/^ ( satis f yiconsequenceiC), Ai)a\ . , 
eonsequenees{A, , A2) ^ fzndall{C, not{member{C, A,)) j ’ 

By applying the domain-specific transformations above to the appropriate 
subgoals of clausesHandH'^e obtain the final definition given in clausesH^ndJ 
below. 
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form_dassification{T, Ii )A (5) 

apply_some{Ii , Xi, best_classification{Ii , Xi), C) 

choose_one{A2,0)A (6) 

apply _some{A 2 , X\, is_attribute{Xi) , A) A 
union{A, T, 7i)A 
consequences{Ti, A3) A 
union{A3, Ti, T„)A 
remove{A, O, 0„)A 
classified{Tn, 0„, C) 

We can execute this in the normal Prolog style and to produce the behaviour 
required at the beginning of this section. 

Our example has shown a notion of refinement which connects different lev- 
els of design but we do not claim that the particular refinement system which 
we have demonstrated is ideal. Much more work remains to be done to make 
it mathematically and pragmatically stable. For instance, we have not shown 
formally that our refinement rules are correct - nor have we argued that they 
give complete coverage of a particular class of logic programs. This is because 
we do not yet believe that we have the most appropriate set of rules. In this 
context, appropriateness is not simply a mathematical question because we will 
require refinements to be chosen by humans. Therefore we expect the details of 
this method to change as this aspect of our work matures. 

4 Conclusions 

Strong notions of pragmatics are necessary in the application of formal methods 
because engineers cannot afford to waste time trying numerous inappropriate 
(but mathematically correct) styles of description before learning ones which 
are appropriate to their style of work. Our descriptions of pragmatics are based 
on patterns of use of logic, tempered with experience in how and where to apply 
these patterns. In Section H we have shown three such patterns; described the 
problems we have tackled using them; and explained some of the factors which 
limit the sizes of our systems. 

One of the advantages of systems with explicit notions of pragmatics should 
be that they can be used cooperatively. If we possess additional knowledge about 
how a specification has been built then perhaps we can use this knowledge in 
other systems which are used to extend or adapt the existing definition. This 
issue isn’t well explored but it is suggested by the methods we have described. 
The notions of parameterisation from Section can be used to supply com- 
ponents for later extension by the techniques of Section ^3 The products of 
either of these two methods could be augmented by meta-interpretation of the 
sort described in Section ^3 An example of what we can do with existing tools 
is given in Q]. 



dassified{T, O, C) 
dassifiediT, O, C) 
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However, the fact that we can potentially communicate between different 
forms of description using a shared formal language doesn’t mean that notions 
of design lifecycle emerge from the blend of methods. Just as was the case for 
individual methods, we need to study the pragmatics of refinement from high- 
level to detailed designs. In Section Jwe introduced an example of this sort of 
system and demonstrate a parallel between it and an existing, informal method. 
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Abstract. This paper describes a class of decision procedures that we have found 
useful for efficient, domain-specific deductive synthesis, and a method for integrat- 
ing this type of procedure into a general-purpose refutation-based theorem prover. 
We suggest that this is a large and interesting class of procedures and show 
how to integrate these procedures to accelerate a general-purpose theorem 
prover doing deductive synthesis. While much existing research on deci- 
sion procedures has been either in isolation or in the context of interfacing 
procedures to non-refutation-based theorem provers, this appears to be the 
first reported work on decision procedures in the context of refutation- 
based deductive synthesis where witnesses must be found. 



1 Introduction 

This paper describes a class of decision procedures that we have found useful for 
efficient, domain- specific deductive synthesis, and a method for integrating this type of 
procedure into a general-purpose refutation-based theorem prover. These procedures 
are called closure-based ground literal satisfiability procedures. We suggest that this is 
a large and interesting class of procedures and show how to integrate these procedures 
to accelerate a general-purpose theorem prover doing deductive synthesis. We also de- 
scribe some results we have observed from our implementation. 

Amphion/NAIF[17] is a domain-specific, high-assurance software synthesis sys- 
tem. It takes an abstract specification of a problem in solar system mechanics, such as 
“when will a signal sent from the Cassini spacecraft to Earth be blocked by the planet 
Saturn?”, and automatically synthesizes a FORTRAN program to solve it. Amphion/ 
NAIF uses deductive synthesis (a.k.a proofs-as-programs [6]) in which programs are 
synthesized as a byproduct of theorem proving. In this paradigm, problem specifica- 
tions are of the form x y[R(v, y)] , where x and y are vectors of variables. We are 
only interested in constructive proofs in which witnesses have been produced for each 
of the variables in y . These witnesses are program fragments. 

Deductive synthesis has two potential advantages over competing synthesis tech- 
nologies. The first is the well-known but unrealized promise that developing a declara- 
tive domain theory is more cost-effective than developing a special-purpose synthesis 
engine. The second advantage is that since synthesized programs are correct relative to 
a domain theory, verification is confined to domain theories. Because declarative do- 
main theories are simpler than programs, they are presumably easier to verify. This is 
of particular interest when synthesized code must be high-assurance. 

P. Flener (Ed.): LOPSTR'98, LNCS 1559, pp . Gl-80, 1999. 
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The greatest disadvantage that general-purpose deductive synthesis systems have 
is that systems based on theorem proving^ are almost always unacceptably inefficient 
unless the domain theory and theorem prover are carefully tuned. This tuning process 
consists of iteratively inspecting proof traces, reformulating the domain theory, and/or 
adjusting parameters of the theorem prover, a process that usually requires a large 
amount of time and expertise in automated reasoning. 

In order to assist in constructing efficient synthesis systems, we are developing a 
tool, Meta-Amphion [10], the goal of which is: given a domain theory, automatically 
generate an efficient, specialized deductive synthesis system such as Amphion/NAIF. 
The key is a technique, that is under development, that generates efficient decision pro- 
cedures for subtheories of the domain theory and then integrates them with a general- 
purpose refutation-based theorem prover. Some success has been achieved with this au- 
tomated technique [14]. However, significantly more research is required to enhance the 
automated process of designing decision procedures to replace subsets of a theory. 

However, we have found that deductive synthesis systems can be manually tuned 
very effectively by manually performing the process we are trying to automate. Hence, 
one can accelerate a deductive synthesis system by manually inspecting a domain theory 
and identifying subtheories for which we already have or can construct replacement de- 
cision procedures. This technique has, in our experience, been far easier and has often 
produced more efficient systems than the traditional technique of inspecting proof trac- 
es and tuning parameters. For instance. Figure 1 summarizes our experience with the 
Amphion/NAIF system. It is a graph of the performance of three different versions of 
Amphion/NAIF. It shows the number of inference steps required to find proofs as the 
input problem specification size (number of literals) grows for an un-optimized system, 
a traditionally hand-tuned system, and a system tuned by replacing subtheories with de- 
cision procedures (Tops). Figure 2 compares the traditionally hand-tuned system vs. the 
system tuned with decision procedures (Tops). 

While much existing research on decision procedures has been either in isolation 
[11] [16] [5] or in the context of interfacing procedures to non-refutation-based theorem 
provers [13] [2], we are unaware of any work done on decision procedures in the context 
of refutation-based deductive synthesis where witnesses must be found. This paper pre- 
sents a decision procedure interface to a theorem prover with several inference rules in- 
cluding binary resolution and paramodulation. These inference rules have been 
extended to enable the class of ground literal satisfiability procedures to be integrated 
with the theorem prover in a straightforward and uniform manner. Procedures can be 
plugged in on a theory-by-theory basis, allowing the theorem prover to be tailored to 
particular theories. We show that when these procedures have the additional property of 
being closure based, they can be used to produce witnesses for deductive synthesis. The 
class of ground literal satisfiability procedures is such that the witnesses produced are 



1. Amphion/NAIF utilizes a refutation-based theorem prover. We initially con- 
sidered using Prolog; however, the domain theory required extensive use of equality, 
making the Prolog implementations available at the time inappropriate. 
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typically straight-line program fragments that are incorporated into larger programs pro- 
duced by the general-purpose theorem prover. 



Inference 

Steps 




Number of Literals in Specification 



Figure 1: A comparison of the performance of three different versions of Amphion/NAIF. 



Steps 




Number of Literals in Specification 

Figure 2: A closer comparison of the two tuned versions of Amphion/NAIF. 



Section 2 introduces separated clause notation, the notation used by our extended 
inference rules. The motivation for these rules is that they enable decision procedures to 
be integrated with the theorem prover and used in place of subsets of a theory. The in- 
tegration of procedures requires procedures that compute satisfiability and procedures 
that compute entailment. Section 3 describes procedures for testing satisfiability in a 
theory. Section 4 describes decision procedures that test entailment in a theory and that 
compute witnesses for deductive synthesis. The example used in Sections 2-4 is in the 
domain of LISP list structure and involves a decision procedure originally developed by 
Nelson and Oppen. This is used for simplicity of presentation. Then in Section 5, a de- 
cision procedure from the Amphion/NAIF domain is described. Section 6 describes the 
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implementation of the interface and the results of using procedures like the one de- 
scribed in Section 5 for deductive synthesis in Amphion/NAIF. Finally, Section 7 dis- 
cusses related work and concludes. 

2 Separated Inference Rules 

This section describes our extension to the inference rules in the SNARK [17] the- 
orem prover enabling the use of decision procedures. The basic idea is that all clauses 
are separated into two parts: a part that is reasoned about by integrated decision proce- 
dures and a part that is reasoned about by SNARK. First, separated clause form is de- 
fined, and then the separated inference rules are described. SNARK has inference rules 
resolution, hyperresolution, paramodulation, and demodulation. The overall extension 
has been accomplished by extending each inference rule in a uniform manner. This pa- 
per only discusses separated binary resolution and separated paramodulation, but the 
other rules are extended similarly. 

Separated binary resolution is similar to resolution with restricted quantifiers or 
RQ-resolution [3]. Recall that, given a first-order theory T and a first-order formula , 
we prove 71= by refutation by showing that T { } is unsatisfiable. Assuming that 

T is satisfiable, this amounts to showing that no model of 7’ is a model of -i . The gen- 
eral idea of our binary resolution rule (as well as RQ-resolution) is as follows. If there 
is a method for determining satisfiability of a formula relative to a theory T'j { } , 

we prove 71= by showing that no model of T’j can be extended to a model of 
T 2 { } , where 7’2=7’-7’j. Our work is an extension of Burckert’s in two ways. First, 

our resolution rule differs from RQ-resolution because it allows function symbols to ap- 
pear in T 2 and -1 . In practice, this is extremely important because it drastically reduces 
the number of potential resolutions that must be considered. Second, we have extended 
the separation idea to inference rules other than resolution. 

The separated rules work with clauses that are separated relative to a subtheory, 
called a restriction theory. 

Definition 2.1 (Separated Clause) Let L be the language of a theory T, a first-order the- 
ory with equality. We treat equality as a logical symbol, so = is not in L. Let Lj L be 
the language of Jj T . A clause C with the following properties is said to be separated 
relative to T^: 

1. C is arranged into Cj C 2 , where both Cj and C 2 are disjunctions of literals (i.e., 
clauses). 

2. All the function and relation symbols in Cj come from L| and all the function and 
relation symbols in C 2 come from L-Lj. 

Notice that C] C 2 can be written Cj C 2 , where Cj is the negation of Cj. Since Cj 
is a disjunction of literals, Cj is a conjunction of the negations of the literals in Cj. If 
C = [Cj C 2 ] is a clause separated relative to some theory, C[ is called the rerfWchon 
of C and C 2 is called the matrix of C. A set of clauses is separated relative to a theory if 
each of the clauses in the set is separated relative to the theory. 

Constant (0-ary function) symbols are not discussed in the definition of separation 
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because they may appear in Cj or C2 regardless of which language they are in. As ex- 
plained helow, this is a property of the mechanism for passing information between the 
matrix and the restriction of clauses as they are manipulated by our extended inference 
rules. 

A clause is separated in two steps. In the first step, literals are placed in the restric- 
tion or matrix of a clause based on their predicate symbol. In the second step, each non- 
constant term f in the restriction whose head symbol is in L-Lj is replaced by a new vari- 
able X, and xt is disjoined to the matrix. Similarly, each non-constant term in the matrix 
whose head symbol is in Lj is replaced by a new variable x, and x=t is conjoined to the 
restriction. 

Example 2.1 Suppose we have a theory T j of LISP list structure whose non-logical sym- 
bols are the function symbols head, tail, cons, and nil.. Then the separation of the for- 
mula tail{K)nil relative to T] is {x=tail(K}) (xnil). 

Separated binary resolution computes a resolvant of two clauses, C’ and C”, each 
separated relative to a theory T^. This resolvant is also a clause separated relative to Tj. 
Informally, a resolvant is computed as follows. First, ordinary resolution is performed 
on the matrices (right hand sides) of C’ and C” to form the matrix of the resolvant. The 
resulting substitution is used in forming the restriction of the resolvant which is the 
conjunction of the restrictions of C’ and C” with the substitution applied. If the new 
restriction is unsatisfiable in T], the resolvant is true and, as a practical matter for reso- 
lution refutation, can be discarded. 

Definition 2.2 (Separated Binary Resolution) Let C’ and C” be variable disjoint 
clauses separated relative to a theory Tj. Let C = j ... Q and 

C = j ... p I2 ^ ’ where Q and R are (possibly empty) clauses and n,pO. If I j 
and I2 unify with most general unifier and [( 1 ... „ 1 ... „) ] is satisfi- 

^ 9 

able in Tj, the separated resolvant of C’ and C” is the separation of 

( 1 ... n 1 ... p) (2 R) . 

Example 2.2 The third clause below is a separated resolvant of the first two clauses. 

{x = cons{u, v)) {K = cons{u, z)) (w = cons(zi, nil)) {z append(v, w)) 

{x^ = tail(K)) (y^ = cons(Up nil)) {{x^ = append(front{x^), y^)) (u last(X[))) 



2 . The separation of the resolvant does not have to be a separate step. However, 

it simplifies the presentation. 
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(x = cons{u, v)) 
((z = tail{K)) 



{K = cons(u, z)) (w = cons{zi, nil)) 
(w = cons{u^, nil))) 



(u last(z)) (v front(z)) 



The literal z append(v,w){in the first clause) is unified with X]=append(front(xj),y]) (in 
the second clause) producing the unifier {xi z,v front(z), vv yjj. The matrix of the 
resolvant is obtained as in ordinary binary resolution and the restriction is the result of 
applying the unifier above to the conjunction of the restrictions of the two parents. The 
resulting clause is separated, moving front(z) to the matrix. 



Lemma 2.1 (Soundness of separated binary resolution) Let be a set of separated 
clauses, and let be a clause derived from two elements of by separated binary 
resolution. If M is a model of , M is a model of { } 

Proof: Soundness follows immediately from the soundness of ordinary binary reso- 
lution. The satisfiability check on the restriction of the resolvant is not necessary for 
soundness of the rule overall. Rather, if the restriction of the resolvant is unsatisfi- 
able, the separated clause is a tautology. [] 

Definition 2.3 (Separated Paramodulation) Let l[t\ be a literal with at least one occur- 
rence of the term t. Let C’ and C” be variable disjoint clauses separated relative to a 
theory Tj Let C = j ... l[t] Q and C = j ... p {r = s) R, 

where Q and R are (possibly empty) clauses and n,p Q If t and r unify with most general 
unifier and [( j ... j ... p) ] k saiisiiahXe, m T i, & separated para- 

modulant of C’ and C” is the separation of 

( 1 ... n 1 ... p) I [S ] Q R 

where I [j ] represents the result obtained by replacing a single occurrence oft in Z 
by 5 . 

As with resolution, soundness of separated paramodulation follows from the 
soundness of the ordinary paramodulation rule. 

An ordinary resolution refutation of a set of clauses C consists of a sequence of 
clauses where each clause is an element of C or is derived from two preceding clauses 
in the sequence by binary resolution or paramodulation. An ordinary refutation is closed 
when the empty clause, which we denote [], is derived. A separated refutation is a se- 
quence of separated clauses derived using the separated rules. Unlike an ordinary refu- 
tation, a separated refutation is not necessarily closed when a clause with an empty 
matrix is derived. Instead, in general, there is a set of clausesjCj [], ..., []} 

each of which has a separated refutation such that T 1= [ Cj ... C^] , where F is 

the existential closure of F. A proof of this fact can be found in [Burckert91] where it is 
also shown that this disjunction is finite so long as T] is first-order (this is a consequence 
of Compactness). Hence, a closed separated refutation is a separated refutation that 
ends with a collection of separated clauses all of whose matrices are empty such that the 
existential closure of the disjunction of their restrictions is a theorem of Tj. 
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Lemma 2.2 (Soundness of separated refutation) If the separation of a set of clauses 
C has a closed separated refutation, C is unsatisfiable. 

Proof: This result follows immediately from soundness of separated binary reso- 
lution and separated paramodulation, and the fact that if a set of separated clauses is un- 
satisfiable, so is the unseparated clause set. [] 

An inference system with ordinary binary resolution and ordinary paramodulation 
is complete if reflexivity axioms are included. In order for a system including separated 
versions of these rules to be complete, separated versions of congruence axioms for 
some theory predicate and function symbols are added. An example of a predicate con- 
gruence axiom is (x = y) {P(x) P{y)) ■ Space does not permit a proof of the com- 

pleteness of separated resolution and paramodulation here. 

[3] points out that for some restriction theories, closed separated refutations can 
always be obtained by considering the entailment of the restrictions of only individual 
clauses. For instance, it is proven that if Tj is a definite theory, i.e., a theory that can be 
written as a set of definite clauses, closed separated refutations are guaranteed for query 
clauses whose restrictions contain only positive literals. This paper focuses on the case 
where entailment of only single restrictions needs to be checked. When this is not the 
case, getting a closed separated refutation requires an additional inference rule (such as 
consensus [7]) or it requires decision procedures to be used in a more complicated man- 
ner than presented here. Thus far, the simpler case has been sufficient in our work on 
deductive synthesis. 

The definition of a separated clause often prevents the derivation of clauses with 
empty matrices when terms that are not in the restriction language appear. These terms 
keep getting separated back into the matrix. For instance in example 2.2 above because 
front is in L-Lj, instead of substituting front(z) into the restriction of the resolvant, 
vfront(zfs disjoined in the matrix. In such cases, the matrix of a clause will end up con- 
taining only literals of the form t xfoi some variable x and some term t in the language 
L-L j not containing x, Such a clause can be viewed as having an empty matrix with the 
disequalities considered as substitutions for variables in the restriction. Our system 
completes refutations by applying these substitutions to the restriction (rendering the 
clause no longer separated) and then checking the entailment of the resultant restriction 
with symbols in L-L j uninterpreted. This can be seen in the last step of the following 
example. 

Example 2.3. Let be a theory of LISP list structure with function symbols head, tail, 
cons, and nil. Given the theory T: 

{x = x) (K nil) {tail{K) nil) 

(K nil) {{lail{K) nil) tail(K) = append{front{tail(K)), cons(last{tail{K), nil)))) 
append(cons{u, v), w) = cons{u, append(v, w)) 

(x nil) (x = cons(head(x), tail(x))) 

(head(cons(x, y)) = x) {tail(cons{x, y)) = y) (cons(x,y) nil) 

we want to show that y^, = append{y^, cons{zi, nil))) is a theorem of T. In this 
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theory, the functions /ro«t (which “computes” all but the last of a list) and last (which 
“computes” the last element of a list) are constrained in terms of the functions append, 
cons, and tail. Witnesses found in proving the theorem above can be viewed as synthe- 
sized definitions of the functions/rowt (a witness for j]) and last (a witness for zj) under 
the assumption for an input list K, that K niland tail(K) nil.Note that we make these as- 
sumptions here so as to focus on the witnesses found by a decision procedure. When 
these assumptions are relaxed, the fragments generated by the decision procedure are 
incorporated into recursive definitions affront and last. 

A refutation that is separated relative to '^LISP is given below. Clauses 1-5 below 
are the first three axioms above separated relative to '^LISP- Note that these are the claus- 
es of T-Tu^p. The last two formulas above are axioms of Tjj^p and are needed only in 
determining satisfiability and entailment of restrictions. Therefore, they do not appear 
in the proof. We give as justification for step 10 “substitute.” The clause of this step is 
obtained from step 9 by treating the disequalities in the matrix as a substitution that is 
applied to the restriction. Since the existential closure of the restriction of 10 is a theo- 
rem of '^LISP (regardless of the interpretation of front and last), the proof is finished. As 
discussed in Section 4, the witnesses for front and last are obtained from the conse- 
quences of the restriction of step 10. 



□ 


Given 


K nil 


a 


Given 


(x = tail(K)) X nil 


3 


Given 


(x = tail(K)) (y = cons(z, nil)) (w = tail(K)) 
{x = nil) (K = nil) (z last(w)) 

(x = append{front(x), y)) 


4 


Given 


(x = cons(u,v)) (y = cons(u, z)) 

((appendix, w) = y) (z append(v,w))) 


B 


Negated conclusion 


(x^ = cons(zi, nil)) (K append(ypxf) 


6 


resolve 4 and 5 


(x = cons(u, v)) (K = cons(u, z)) (w = cons(zi, nil)) 




{yj w,y K} 


(z append(v,w)) 


7 


resolve 1 and 3 


(x = tail(K)) (y = cons(u, nil)) 

(x = nil) (x = append(front(x), y)) 
(u last(x)) 


8 


resolve 2 and 7 


(X[ = tail(K)) (yj = cons(u^, nil)) 

(x^ = append(front(xf),yf)) (u last(xf)) 


9 


resolve 8 and 6 


(x = cons(u, v)) (K = cons(u, z)) (w = cons(zi, nil)) 




Xj z, V front(z), 


(z = tail(K)) (w = cons(u^, nil)) 




w yj 


(mj = last(z))(v front(z)) 
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10 


substitute 


(x = cons(u, front(z))) (K = cons(u, z)) 
(w = cons(zi, nil)) {z = tail(K)) 

{w = cons(last(z), nil)) 






[] 



3 Procedures for Testing Satisfiability 

The separated inference rules presented in the previous section depend on proce- 
dures which perform two actions. These are (1) a test for satisfiability of restrictions; 
and (2) a test for entailment of the restriction of any formula which has an empty matrix. 
This section describes procedures that test satisfiability of restrictions. We identify a 
class of procedures that can be used for this purpose. 

When we have a procedure for deciding satisfiability of a conjunction of literals 
in a theory Tj T , we use separated inference rules to prove a theorem in a theory T. 
The clauses of T-Tj and -i are separated relative to Tj, and the procedure is used at 
each inference step to test the satisfiability of derived restrictions. 

The restrictions are conjunctions of literals possibly containing variables. Even 
though these restrictions may have variables, it is possible to use ground literal satisfi- 
ability procedures (GLSPs) to determine satisfiability of the conjunctions in restric- 
tions. We do this by replacing the variables in the restrictions by new constant symbols. 
The fact that we can use GLSPs to determine satisfiability here is established by Theo- 
rem 3.1. 

Definition 3.1 (Ground Literal Satisfiability Procedure) A ground literal satisfiabil- 
ity procedure for a theory Tis a procedure that decides whether or not a conjunction of 
ground literals F is satisfiable in T. The language of F must be the language of 7 but may 
be extended by a collection of uninterpreted function symbols (including constants). 

Theorem 3.1 (Applicability of GLSPs) If P is a GLSP for a theory Pj, P can be used 
to decide the satisfiability in P| of the restriction of any clause separated relative to Pj. 
Proof: Let C = [Cj Cj] be a clause separated relative to Pj. Let X],...,x„ be the 
variables in Cj . Let be the substitution {x^ Cj.,.. , c^} , where the q are 

new uninterpreted constant symbols. Replace the restriction of C with 
(Xi = Ci) ... (x„ = c„) Cl . 

We show that (a) (xj = Cj) ... (x^, = c^^) Cj is satisfiable just in case Cj is and 

(b) the satisfiability of C implies the satisfiability of 
((Xj = Cj) ... (Xjj = q) Cj ) Cj . Note that a conjunction of equalities con- 
structed in this fashion is always satisfiable. Hence, we can replace any separated 
clause C with the clause ((xj = Cj) ... (x^ = c^) Cj ) Cj and decide the sat- 

isfiability of the restriction of such a clause by deciding the satisfiability of the 
ground conjunction Cj . 

(a) Since Cj is the generalization of a subconjunction of 
(xj = Cj) ... [x^ = Cj^) Cj ,if (xi=Ci) ... (Xj, = c^) Cj is satisfiable, Cj 
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is satisfiable. Now suppose Cj is satisfiable in a model M under the variable assign- 
ment I. Extend M to M* which interprets each c,- the same as I assigns Xj. Then 
<M ,I> \={x■^=c^) ... (x^ = cj Cj . 

(b) If C is satisfiable, either C 2 is satisfiable or Cj is unsatisfiable. If C 2 is satisfiable, 
then ((xj = Cj) ... ^1 ) ^2 satisfiable. Otherwise, since Cj is 

satisfiable just in case (Xj = Cj) ... (v„ = Cj,) Cj is, 

(X[ = C[) ... {x^ = Cjj) C[ is also unsatisfiable. [] 

The fact that any GLSP can be interfaced to the separated inference rules is a for- 
tunate situation because there appear to be a large number of useful GLSPs. The argu- 
ment supporting this claim has three parts. First, a significant number of GLSPs have 
been identified and published [1 1][12][5]. Second, other work reports on techniques for 
extending some GLSPs that have been identified. Third, there are techniques that enable 
GLSPs to be combined. 

Nelson & Oppen in [12] show how to extend a GLSP for the theory of equality 
with uninterpreted function symbols to the theory Tj^j^p Their procedure can be integrat- 
ed with our theorem prover and used to check satisfiability of restrictions in the running 
example, e.g., the restriction of the clause derived in step 9 of Example 2.1 

{x = cons(u, v)) (K = cons(u, z)) {w = consiz^, nil)) (z = tail{K)) 

(w = cons{uy, nil)) 

can be checked for satisfiability in the theory of LISP list structure using Nelson & Op- 
pen’s procedure considering all the variables to be constants. 

We have used techniques similar to Nelson & Oppen to construct several new pro- 
cedures by extending a GLSP for congruence closure (one such procedure is described 
in Section 5). Also, [8] gives techniques for constructing GLSPs based on congruence 
closure for conjunctions of ground literals containing predicates. The essential idea is to 
introduce boolean constants True and False and to represent P{t^,...,t^) as 
P(t[, ..., tjj) = True and P{t^, ..., t^) as P(fj, ..., t^) = False . Then, if the congru- 
ence closure graph of a conjunction F contains True=False, F is unsatisfiable. 

Finally, both [11] and[16] describe techniques for combining GLSPs with disjoint 
languages into a GLSP for the union of these languages. Much work has been done re- 
cently on the closely related topic of combining decision procedures for equational the- 
ories [1]. 

Hence, we are in the convenient situation of being able to combine GLSPs to cre- 
ate a GLSP for a restriction theory. Given a theory T, we can design from components 
a decision procedure for a restriction theory. (See [10] or [14] for examples of tech- 
niques for automatically designing decision procedures from components.) 

4 Deductive Synthesis Decision Procedures 

This section shows that if a GLSP has the additional property of being closure- 
based it can be used not only to check satisfiability but also to check for entailment and 
to produce witnesses for deductive synthesis. All of the procedures mentioned in Sec- 
tion 3 as well as all of the procedures we have used in our work on deductive synthesis 
are closure based. 
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As discussed in Section 2, producing a closed separated refutation requires deci- 
sion procedures for computing both satisfiability and entailment of restrictions. For the 
entailment problem, we need decision procedures that check the entailment of clauses 
containing existentially quantified variables and possibly also to produce witnesses for 
those variables. We call such procedures literal entailment procedures. 

Definition 4.1 A literal entailment procedure (LEP) for a theory F is a procedure that 
decides for a conjunction of literals F in the language of T (possibly containing free vari- 
ables) whether or not 71= F. 

While in general the satisfiability procedure and the entailment procedure for a re- 
striction theory are separate procedures, we have found that closure-based GLSPs can 
also be used as LEPs. 

Definition 4.2 (Closnre-based satisfiability procedure) A closure-based satisfiability 
procedure for a theory T computes satisfiability in F of a conjunction of formulas by 
constructing a finite set of ground consequences of F { } such that contains a 
ground literal and its negation just in case is unsatisfiable in T. 

The congruence closure procedure is a closure-based satisfiability procedure for 
the theory of equality with uninterpreted function symbols. It constructs a congruence 
closure graph [8] and in so doing computes a finite set of ground consequences of a con- 
junction of input ground equalities. As new equalities are added to a conjunction, new 
nodes representing terms are added to the graph and/or congruence classes are merged. 
Many GLSPs that extend congruence closure are also closure-based satisfiability proce- 
dures. 

A closure-based GLSP with theory T can be used as a LEP as follows. Given a con- 
junction of literals 7^(xj,...,x„), where the x; are the existentially quantified variables in 
F, the procedure is used to check the satisfiability of T {F(c],...,c„)}, where the c; are 
new constant symbols substituted for the corresponding variables. Since the procedure 
is closure based, in computing satisfiability, it computes consequences of 
T {/^(ci,...,Cn)}. If consequences of the form cpt; are computed for all i=l,...,n, the pro- 
cedure is run again on -iF(tp...,t^). If this clause is unsatisfiable in T, witnesses have 
been identified for the original variables xj. The idea of the first call to the procedure is 
to determine if in every model of T {/^(cj,...,Cn)}, cptj, i=l,...,n. The idea of the second 
call is to determine if F{ti,...,t^) is true in every model of T, i.e., 71= F. 

We illustrate how a closure-based satisfiability procedure is used as a LEP with 
Nelson & Oppen’s GLSP for 

Example 4.1 In step 10 of example 2.3, it must be shown that the existential closure of 
F(x, u, z, w, Zj) = 

(x = cons(u, front(z))) (K = cons(u, z)) (w = cons(zi, nil)) 

(z = cons(u, front(z))) {w = cons(last(z), nil)) 

is a theorem of '^LISP- Eirst, the Nelson & Oppen GLSP is used to check the satisfiability 
of this conjunction (assuming that the variables are uninterpreted constants). In doing 
so, the procedure computes the following additional equalities. From K=cons{u,z), we 
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get u=head{K) and z=tail{K). Hence, x=cons{head{K)front{tail{K)). From 
w=cons{z\,nil) and w=cons{last{z),nil), we get 

head{cons{z\,nU))=head{cons{last{z),nd)). 

Hence, z\=last{z) and z\=last{tail{K)). 

What the procedure has shown is that if we treat the variables in the above formula 
as constants, in every model of T that is also a model of this formula, 

x=consihead(K)front{tail{K})) and Z\=last{tail{K)). That is, that F{c^, c^, c^, c^, is 
satisfiable in the theory '^LISP and that c-^=cons(head(K)front(tail{K))) and 
= last{tail{K)) . Next, to establish that is a witness for 

X and that last(tail(K)) is a witness for z\, the procedure is used to check the unsatisfi- 
ability of F(tj, . . ., tjj) . Since this is a disjunction that is unsatisfiable just in case all of 
its disjuncts are, each literal of can be checked separately. If 

F(fj, ..., t^) is unsatisfiable, T l=F(tj, ..., and 71= F. We have exploited the fol- 
lowing fact in this analysis. 

Lemma 4.1 Let F{c\,...,Cy) be a conjunction of ground literals that is satisfiable in a the- 
ory T. Further, suppose that the constant symbols cj,...,c„ do not occur in T. If 

T F(cj, ..., c^) 1= ((C[ = t[) ... (c„ = fj,)) where each tj is a term not containing any 

of the CyS, r 1= x^, ...,x^(F(x^, ...,xj ((xj = fj) ... = ?^))) . 

Proof: Suppose T F(cj, ...,c„)l=((ci = fi) ... (c„ = t„)) . Then, by the de- 
duction theorem, T 1= (F(cj, ..., Cj,) ((cj = tj) ... (c^ = t^))) , Also, since the q do 

not appear in T, the first-order law of universal generalization gives us 
T\= Xi, ...,x^{F{xi, ...,xj ((xi = fi) ... (x„ = q))).[] 

Lemma 4.1 gives us license to use a GLSP to find potential witnesses for existen- 
tially quantified variables, i.e., terms that make F true in every model of T {F}. The 
GLSP is then used to check that these potential witnesses are, in fact, witnesses, i.e., that 
they make F true in every model of T. 

We have used the separated refutation system in the context of deductive synthesis 
where we are only interested in constructive proofs in which witnesses have been pro- 
duced for existentially quantified variables in a theorem. In this context, decision pro- 
cedures may be required to produce witnesses. Closure-based GLSP have an added 
benefit in deductive synthesis, namely that such a GLSP establishes that the existential 
closure of a restriction is a theorem by constructing witnesses. These witnesses can be 
extracted to produce programs in deductive synthesis. For example, in proving the the- 
orem y j, zj [F = appendiy^, consiz^, nil))] in example 2.3, the Nelson & Oppen GLSP 
produces witnesses foryj and zj. These are cons{head{K)front{tail{K)) and last(tail(K)) 
respectively, which are the synthesized programs for front(K) and last(K) under the as- 
sumption that Knil and tail{K)nil. 

Thus far in our deductive synthesis work, all the GLSPs we have developed can be 
used to generate witnesses in this manner. 
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5 Amphion/NAIF Decision Procedures 

This section discusses the implementation of procedures for Amphion/NAIF. Am- 
phion/NAIF is a deductive-synthesis system that facilitates the construction of programs 
that solve problems in solar system mechanics. Programs generated by Amphion/NAIF 
consist of straight-line code using assignment statements and calls to elements of the 
SPICE subroutine library. The SPICE library was constructed to solve problems related 
to observation planning and interpretation of data received by deep space probes. 

An Amphion domain theory has three parts: an abstract theory whose language is 
suitable for problem specifications, a concrete theory that includes the specification of 
the target components, and an implementation relation between the abstract and con- 
crete theories. Specifications are given in the abstract language, and programs are gen- 
erated in the concrete language. Abstract objects are free from implementation details. 
Eor example, a point is an abstract concept, while a FORTRAN array of three real num- 
bers is a concrete, implementation level construct. 

At the abstract level, the Amphion/NAIF domain theory includes types for objects 
in Euclidean geometry such as points, rays, planes, and ellipsoids, augmented with as- 
tronomical constructs such as planets, spacecraft, and time. The abstract functions and 
relations include geometric constraints such as whether one geometric object intersects 
another. The concrete portion of the Amphion/NAIF domain theory defines types used 
in implementing a program or in defining representations, and it defines the subroutines 
and functions that are elements of the target subroutine library. 

The implementation relations are axiomatized through abstraction maps using a 
method described by Hoare [9]. These are maps from concrete types to abstract types. 
The function abs is used to apply an abstraction map to a concrete object. For example, 
abs{coordinates-to-time(TS), tc) denotes the application of the abstraction map coordi- 
nates-to-time, parameterized on the time system TS, to the time coordinate tc, i.e., this 
term maps a concrete time coordinate tc in time system TS to an abstract time. 

In the NAIF theory, many implementation relations are axiomatized as equalities. 
For example, an abstract time may be encoded by any of several data representations 
such as Julian date or Calendar date. An example of an equality axiom relating two con- 
crete objects to a single abstract object is 

abs{coordinates-to-time{ts tc) = 
t 5 j, tS2, tc ^j2s{coordinates-to-time{tS2), convert-time{ts^, tS2, tc)) 

This axiom says that two abstract times are equivalent. The first abstract time is 
derived from time coordinate tc in time system tsj. The second abstract time is the time 
conversion function convert-time applied to the first time coordinate to convert it from 
one system to another. This axiom is used to introduce invocations of the convert-time 
function into a synthesized program. These synthesized code fragments convert time 
data from one representation to another. 

The terms in a specification usually do not match perfectly with axioms in the do- 
main theory. Inference steps are required to generate matching terms. When these infer- 
ence steps include resolution or paramodulation, choice points are introduced into the 
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theorem prover’s search space. For example, a specification may state that an input time 
is in the Julian time system, but it may require that the time be in the Ephemeris time 
system for the appropriate inferences to carry through. The theorem prover will apply 
the convert-time axiom (using paramodulation) to convert the input time coordinate 
from Julian to Ephemeris, then apply the appropriate inferences. Each paramodulation 
represents a multi-branched choice point in the search space. As a practical matter, this 
branching usually causes a combinatorial explosion in theorem proving. One class of 
decision procedure interfaced to the theorem prover in Amphion/NAIF performs repre- 
sentation conversions, like the time conversion just described, without search. In Am- 
phion/NAIF, inserting decision procedures to eliminate choicepoints has a dramatic 
speedup effect. 

5.1 A Procedure for Time Conversion 

The procedure for time conversion is the simplest example of a representation con- 
version decision procedure used in Amphion/NAIF. When this procedure is interfaced 
to the theorem prover, the domain theory is separated relative to the NAIF subtheory of 
time. For example, an axiom such as 

sum-of-limes {abs{coordinates-to-time (EPHEMERIS), f j ), 

, , abs(coordiruites-to-time{EPHEMERIS), t-,)) = 

abs(coordinates-to-time(EPHEMERIS), sum-time-coords (tp 12)) 

is separated, yielding 

(Aj = abs(coordinates-to-time(EPHEMERIS), U2)) 

(X2 = abs(coordinates-to-time(EPHEMERIS), U^)) 

(A3 = abs(coordinates-to-time(EPHEMERIS), sum-time-coords (U 2, U^))) 
(sum-of-times(Xp X2) A3) 



The decision procedure implements congruence closure to compute the conse- 
quences of a set of equalities some of which are between abstract time terms, i.e., it is 
used on the restriction of clauses like the one above. The congruence closure algorithm 
computes the consequences of a conjunction of ground equalities by maintaining equiv- 
alence classes of terms in a congruence closure graph [8]. As described in Sections 3 
and 4, for this purpose, the variables in the restriction are treated as constants. These 
constants are specially marked to distinguish them from constants appearing either in 
the domain theory or an input specification. The equivalence classes of two terms are 
merged either when an equality between those terms is introduced or when two terms 
are found, by congruence, to be equal, i.e., if h=5,, then 

f(tp ..., tj = /(ij, ..., ij,) . Hence, the equalities involving abs terms appearing in the 
restriction of a clause and the consequences of those equalities are represented in a con- 
gruence closure graph, rather than as literals of a clause. 

The time conversion procedure is, in fact, an extension of congruence closure be- 
cause it also finds witnesses for some of the specially marked constants (those that were 
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substituted for variables) in abs terms. When a term in an equivalence class of abs terms 
is ground, witnesses are produced for variables in the other terms in the class when those 
other terms contain (non variable) time systems. There are two cases. Case 1 is when 
the time systems in the two abs terms are the same. In this case witnesses are generated 
based on the domain theory axiom 

Is, Ic^, tC2(abs(coordiruites-to-time{ts), tCj) = abs(coordinates-to-time(ts), tc^)) 

(tC[ = tCj) 

Case 2 is when the time systems are different. These witnesses are produced based 
on the domain theory axiom 

tS2, tc{abs(coordinales-lo-time(tSi), tc) 

=abs(coordinates-to-time{tS2), convert-time{ts^, tS2, tc))) 

For example, if there is an equivalence class containing the term abs{coordinates- 
to-time(EPHEMERIS),A) and containing the term abs(coordinates-to- 
timeiJULIAN),tc), the procedure produces the witness convert-time(EPHEMER- 
IS, JULIAN, A) for tc. 

When the convert-time procedure is used in Amphion/NAIF, the axioms above are 
no longer needed. Hence, they are removed from the domain theory. 

5.2 A Proof Using the Time Conversion Procedure 

The axiom shown below indicates how a sum of two times is computed. In this ax- 
iom, the final time is computed as a sum only if both times are in Ephemeris represen- 
tation 

sum-of-times (abs{coordinates-to-time {EPHEMERIS), f j ), 

, , abs{coordinates-to-time{EPHEMERIS), tA) = 

abs{coordinates-to-time{EPHEMERIS), sum-time-coords {t ^2)) 

The operation of the convert-time procedure can be demonstrated by supposing 
SNARK is given the following specification. 

sum-of-times (abs{coordinates-to-time (JULIAN), jt), 
jt, et, ut abs{coordinates-to-time{EPHEMERIS), et)) = 

abs{coordinates-to-time{UTC), ut) 

This specification asks: when given two distances, one represented in JULIAN 
format and one in EPHEMERIS format, find the sum of those distances in UTC format. 
The first step in the proof of this specification is to negate the conclusion and generate 
the Skolem form. Then jt and et become new Skolem constants, and ut becomes univer- 
sally quantified. This formula separated relative to the NAIE theory of time is: 

(F[ = abs{coordinates-to-time{JULIAN), jt)) 

{Y2 = abs{coordinates-to-time{EPHEMERIS), et)) 

(T3 = abs{coordinates-to-time{UTC), ut)) 

(sum-of-times (Y Y2) F3) 
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The conjunction in the antecedent is the restriction which is stored as a congruence 
closure graph. The disequality is the matrix available to SNARK's extended inference 
rules. SNARK unifies the matrix of the above formula with the complementary literal 
in the (now rewritten) sum-of-times axiom, shown below. 

(Aj = abs{coordinates-to-lime{EPHEMERIS), U2)) 

(X2 = abs{coordinates-to-time{EPHEMERIS), U^)) 

(Aj = abs{coordinates-to-time{EPHEMERIS), sum-time-coords {U 2, U^))) 
{sum-of-times{X^, X2) X^) 



The unifier {Tj Aj, F2 ^2’ ^3 A3} is obtained. The matrix of the resolvant 

is the empty clause. The unifier is then passed to the convert-time procedure which now 
attempts to merge the closure graphs of the two restrictions. This generates the follow- 
ing three equalities: 

abs(coordinates-to-time(JULIAN), jt) = abs(coordinates-to-time{EPHEMERIS), U2) 

abs{coordinates-to-time{EPHEMERIS), et) = abs{coordinates-to-time{EPHEMERIS), U^) 

abs(coordinates-to-time(UTC), ut) = 
abs(coordinates-to-time(EPHEMERIS), sum-time-coords {U 2, U^)) 

Since jt and et are constants, the procedure determines that a binding can be gen- 
erated for variables U2 and U^- The procedure then generates the witness U2 convert- 
time{JULlAN, EPHEMERIS, jt). Also the binding et is generated for the second 
equality literal. 

Finally, the variable ut is bound to the term convert-time{EPHEMERIS, UTC, 
sum-time-coords{convert-time(JULIAN, EPHEMERIS, jt), et)). This term is the answer 
term bound to the existentially quantified variable in the original specification. This 
term is a program that converts jt to ephemeris time, adds this converted time to et (al- 
ready in the EPHEMERIS time system), and converts the resultant time to the UTC time 
system. 

6 Implementation 

We have augmented the SNARK resolution theorem prover with the separated in- 
ference rules described previously. We have also added a set of decision procedures to 
SNARK specifically for Amphion/NAIE and used the resulting system to generate pro- 
grams. This section describes the results of this work. This work has been motivated by 
research into Meta-Amphion; however, a detailed discussion of Meta-Amphion is out- 
side the scope of this paper. We believe that the work presented here is of general inter- 
est in its own right because it shows a new way of accelerating deductive synthesis 
engines, specifically full first-order refutation-based theorem provers, using decision 
procedures. 

Our experience with Amphion/NAIE has been that the performance of the theorem 
prover has been an important consideration in the maintenance of the system. As with 
all general purpose theorem provers, SNARK is subject to combinatorial explosion in 
the search for a solution to a problem. As shown in Figure 1 , the search space for all but 
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the smallest problems is unacceptable when using an untuned system. 

A great deal of time and effort has been devoted to tuning Amphion/NAIF. Figure 
1 shows that the hand tuning (done over the course of a year and a half by an expert in 
deductive synthesis) was very effective in reducing the synthesis time, frequently reduc- 
ing the time from hours or days to minutes. The central problem has not been the lack 
of success in tuning Amphion/NAIF; it has been the cost in time and effort required to 
tune the system particularly after the domain theory has been modified. The goal of 
Meta-Amphion is to assist in the construction and maintenance of deductive synthesis 
domain theories, and in particular, to assist in tuning declarative domain theories. 

In general, a deductive synthesis system is tuned by generating example problems, 
observing the system as it attempts to solve the problems, then tuning the system to di- 
rect it towards solutions for the example problems. There are two primary methods of 
tuning the system; (1) changing the agenda ordering, and (2) reformulating the domain 
theory axioms. 

SNARK selects an unprocessed formula from the set of supported formulas, then 
applies every applicable inference rule to the formula, possibly constructing many new 
(unprocessed) formulas. The agenda-ordering function orders formulas after each infer- 
ence step, in effect choosing the next supported formula to be processed. 

The original, general-purpose agenda-ordering function sorted formulas on the ba- 
sis of the size (number of sub-terms) and the number of abstract terms in the formula. 
Thus SNARK favored formulas with fewer abstract terms. It also searched for solutions 
with a smaller number of terms before looking at larger terms. (SNARK only completes 
its search when a ground, concrete term is found for each output variable.) Since smaller 
answer terms represent shorter programs, shorter programs are generated before longer 
ones. 

The hand-tuned agenda-ordering function weighs each formula according to sev- 
eral factors. In addition to the number of abstract terms in a formula, the hand-tuned 
agenda-ordering function also counts the number of non-ground convert- time terms. 
Formulas with more non-ground convert-time terms appear lower on the agenda. This 
prevents SNARK from generating terms such as 

convert-time{Ephemeris, Julian, convert-time {Julian, Ephemeris, tcj). 

This term results in the conversion of a time coordinate from the Ephemeris time system 
to the Julian time system and back again. The agenda ordering function has similar 
weighting schemes for other terms for which tuning has been necessary. 

When the decision procedures are used, the procedure for coordinates-to-time 
collects all the abstract time terms. It delays generating a convert-time term until a 
ground convert-time can be constructed. 



3. In this case, this formula is rewritten by two rules into an identity. However, 
with paramodulation, new variables are introduced. No rewriting occurs since 
the new variables do not match. The result is that chains of convert-time terms 
may be generated. Each of these terms is then a target for resolution or para- 
modulation to generate more formulas, none of which lead to a solution. 
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We compared the performance of three Amphion/NAIF systems: an untuned sys- 
tem with a simple agenda-ordering function; an extensively hand-tuned system; and a 
system which uses several decision procedures. The untuned system describes the state 
of Amphion/NAIF prior to expert tuning. This is exactly the type of system we expect 
Meta-Amphion to be given as input. The hand-tuned system was the result of extensive 
tuning by a theorem proving expert. Not only was a specialized agenda ordering func- 
tion developed, but several of the axioms were reformulated to force the theorem prover 
to behave in a particular manner. Such reformulation depends on in-depth knowledge of 
the workings of the theorem prover. For the decision procedure system, a set of five de- 
cision procedures was written and used. Each of these procedures was interfaced to 
SNARK using the inference rules described previously. 

The domain theories for each of these systems consisted of approximately 325 
first-order axioms. Many of these axioms are equalities, some of which are oriented and 
used as rewrite rules. A series of 27 specifications was used to test these synthesis sys- 
tems. These specifications ranged from trivial with only a few literals to fairly complex 
with dozens of literals. Thirteen of the specifications were obtained as solutions to prob- 
lem specifications given by domain experts, thus this set is representative of the prob- 
lems encountered during real-world use. 

As shown in Figure 1, the untuned system showed exponential behavior with re- 
spect to the specification size for the number of inference steps (and the CPU time) re- 
quired to generate a program. The hand-tuned and decision-procedure-tuned (TOPS) 
systems both grew much less rapidly, with the decision-procedure-tuned system grow- 
ing at about one third the rate of the hand-tuned system in the number of inference steps 
required to obtain a proof, as shown in Figure 2. 

The performance of the system using the decision procedures was unaffected by 
changing between the simple and sophisticated agenda-ordering functions. This is not 
surprising since the decision procedures and the hand tuning both targeted the same in- 
ferences, and when using the procedures, the terms counted by the agenda ordering 
function are hidden inside the data structures of the procedures. 

Although the programs generated using the decision procedures were not always 
identical to programs generated without them, for each case we proved that the pro- 
grams computed the same input/output pairs. 

7 Conclusion 

A major hindrance to the construction and use of deductive synthesis systems is 
the cost associated with constructing and maintaining the domain theories associated 
with them. A primary cost of maintaining a domain theory is the cost of tuning the de- 
ductive synthesis system to the theory. Our work continues on the Meta-Amphion sys- 
tem whose goal is to automatically design specialized deductive synthesis systems from 
untuned domain theories. Much of our effort is on techniques to automate the process 
of replacing subtheories with automatically generated decision procedures. The deci- 
sion procedure design process is one of design from components, where the components 
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are parameterized procedures. The process involves combination and instantiation. The 
component procedures turn out to be closure-based ground literal satisfiability proce- 
dures. As described in this paper, we have also found this class of procedures useful in 
a new type of hand-tuning of deductive synthesis systems. We have defined the class 
of closure-based ground literal satisfiability procedures, introduced extensions of a ref- 
utation-based general-purpose theorem prover to enable any procedure in this class to 
be integrated with the theorem prover to accelerate deductive synthesis, and proven that 
these extensions are correct. 

We have shown how we have used the manual decision procedure insertion tech- 
nique to accelerate Amphion/NAIF, a system that is in regular use by NASA space sci- 
entists. Also, we are using the technique in the development of other “real-world” 
systems such as a system to synthesize three dimensional grid layouts in Computational 
Fluid Dynamics and a system to automatically generate schedulers for Space Shuttle 
payloads. 

The research methodology we are employing is to manually identify sets of axi- 
oms that give rise to combinatorial explosion problems in theorem proving, just as we 
do when tuning manually. Then we generalize these problems into problem classes and 
create generalized solutions in the form of parameterized decision procedures. These 
parameterized procedures are added a library in Meta-Amphion. Meta-Amphion also 
has an evolving library of techniques that enable it to analyze a domain theory, identify 
instances of problem classes for which it has a decision procedure, and automatically 
instantiate the procedure for the problem class. Meta-Amphion also proves that the pro- 
cedure is a solution to the specific problem, then modifies the domain theory appropri- 
ately. 

In general, the soundness of solutions found using decision procedures very much 
depends on the soundness of the procedures themselves. Another ongoing activity in the 
Meta-Amphion project is to develop methods for proving the correctness of parameter- 
ized decision procedures. 
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Abstract. In this paper we propose a method for program synthesis 
from constructive proofs based on a particular proof strategy, we call 
dischargeable set construction. This proof-strategy allows to build proofs 
in which active patterns (sequences of application of rules with proper 
computational content) can be distinguished from correctness patterns 
(concerning correctness properties of the algorithm implicitly contained 
in the proof). The synthesis method associates with every active pattern 
of the proof a program schema (in an imperative language) translating 
only the computational content of the proof. One of the main features of 
our method is that it can be applied to a variety of theories formalizing 
ADT’s and classes of ADT’s. Here we will discuss the method and the 
computational content of some principles of particular interest in the 
context of some classes of ADT’s. 



1 Introduction 



The general idea of Constructive Program Synthesis is that a constructive 
proof of a specification S implicitly contains an algorithm to solve S. A 
popular approach to Constructive Program Synthesis is known as proofs- 
as-programs (see, e.g., BQ) and is based on the fact that constructive 
proofs can be (almost) directly interpreted as executable programs us- 
ing, for example, the Curry-Howard isomorphism, or other kinds of op- 
erational interpretations, like the one in Other approaches, as e.g. 

similar strategy to classical proofs for which a translation 
in a constructive system can be given. The essence of these approaches 
is that a proof (or a translation of a proof into an appropriate functional 
programming language) can be directly executed by a suitable computa- 
tional model assigning computational meaning to every rule of the cal- 
culus in hand. But, as it is well-known (|j])) the proof of a specification 
does not only contain the information needed to compute the solution 
of the specification, the so-called computational content of the proof but 
it also contains information related to the correctness proof of the inner 
algorithm. The presence of this irrelevant information makes inefficient 
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a “naive” approach to program synthesis and “pruning” operations are 
needed to obtain more efficient programs QB- 

In this paper we follow a different approach, we call program-extraction, 
in which we do not give a computational content to every rule of the cal- 
culus in hand, but only to some patterns of rules. These patterns, we 
call active-patterns, can be directly translated into program schemata in 
a target programming language (here we use an imperative language), 
while correctness-patterns are ignored. 

The identification of active and correctness patterns follows from the 
development of a proof method based on the notion of dischargeable set 
which has been deeply investigated in Q. In that work it is shown how 
to build a dischargeable set for a given specification corresponds to build 
a proof (in a natural deduction calculus) with a given structure, and this 
structure allows to distinguish active patterns from correctness patterns. 

In this paper we will not discuss in detail the notion of dischargeable 
set, but we will concentrate our attention on the computational content 
of some interesting active-patterns related to the application of certain 
rules. In particular we will discuss some “non-standard” induction rules 
giving rise to interesting program schemata. 

Another feature of our method is that it can be applied to first-order 
theories formalizing Abstract Data Types (ADT’s for short) and classes of 
ADT’s according to the characterization based on the notions of closed 
and open framework discussed in literature in and, with another 

terminology in The synthesis of programs in the context of open 
frameworks (formalizing classes of ADT’s) allows to construct programs 
parametric in some functions and procedures; in any instantiation of the 
open framework (that is in any ADT of the corresponding class) the 
instantiation of the parametric program gives rise to a completely defined 
program. According to this consideration we can say that our method 
provides a mechanism of software reusability. 

The paper is so organized. In the next section we will discuss the 
notions of open and closed framework that will constitute the axiomati- 
zations of ADT’s and classes of ADT’s in which we will write the specifi- 
cations defined in SectionH In SectionBwe introduce, by examples, the 
notion of dischargeable set, which is formally described in Appendix^] 
In SectionHwe discuss the computational content of some induction prin- 
ciples by showing the related program schemata. 
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2 ADT specifications 

In this paper we will always consider specifications in the context of an ax- 
iomatization characterizing ADT’s or classes of ADT’s. To do so we begin 
by introducing the fundamental definitions of open and closed framework. 
Intuitively, a framework is a first-order theory embodying all the relevant 
knowledge of the problem domain of interest. We endow frameworks with 
isoinitial semantics. For a detailed discussion on frameworks we refer the 
reader to and to , where they have been introduced with a differ- 
ent terminology. We remark that in this work we are interested in program 
synthesis from constructive proofs, but we also want to treat ADT’s in the 
usual context of classical semantics. In this sense our choice of isoinitial 
semantics, instead e.g. of the more usual initial semantics, is motivated; 
indeed, under some conditions, theories with isoinitial model can be com- 
bined with constructive logics giving rise to constructive systems (for a 
detailed discussion we refer the reader to BQ). 

A (many sorted) signature A is a triple (Sorts, Fun, Rel), where Sorts 
is the set of sort symbols and Fun and Rel are sets of function declarations 
and relation declarations respectively. The first-order language over 
S is defined as usual starting from U and the set of logical constants A, 
V, — - 1 , V and 3. 

A closed framework is a pair T = (A, T), where A is a many sorted 
signature and T is a A-theory (that is a theory whose axioms are wff’s 
of Ljf) defining in a unique way (in a sense which will be clear later) all 
the symbols in A. 

We will present frameworks according to the following example for- 
malizing the usual Peano Arithmetic: 

Framework PA 

Sorts : N ; 

Functions : 0 N ; 

s : N ^ N ; 

+ , • : ^ N ; 

Axioms : V® (^0 = s(a;)) ; 'ix,y(s(x) = s{y)^x = y) ; 

\/x[x + 0 = ; \/x, y{x + s[y) = s{x + y)) ; 

^xlx -0 = 0) ; V®, y{x ■ s{y) = x + x ■ y)) ; 

H*{0) A\/x{H*{x)-^H*{sxy)^\/xH*{x) 

In the induction principle, H* indicates a schema variable, that is H*(0) A 
\lx{H*{x) H*{s{x))) ~^\lxH*{x) is a shorthand for the infinite set of 

axioms obtained by substituting any wff of the language of PA for H* . 

Differently from a closed framework, which completely defines a the- 
ory, an open framework depends on some parameters and characterizes 
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a class of theories. To formalize this feature some definitions are in or- 
der. A parametric signature is a signature A’(P) where some symbols and 
declarations, the ones occurring in the list of parameters P, are put into 
evidence as parameters (see, e.g., ^3). A parametric theory T(P) over 
P{P) is any A(P)-theory. We can write T(P) = Cp U Ax, where Cp 
is the set of constraints, that is axioms only containing parametric sym- 
bols and Ax is the set of internal axioms, axioms containing at least a 
defined (i.e., non-parametric) symbol. The internal axioms are intended 
to formalize the defined symbols of P{P), while the constraints represent 
requirements to be satisfied by actual parameters. The operation of in- 
stantiation is formally modeled by the notion of signature morphism, a 
map between signatures preserving arities and sorts, see 



An open framework is a pair P{P) = {P{P), T(P)) where P{P) is a 
parametric signature and T(P) is a i7(P)-theory. An example of an open 
framework is: 

Framework LIST(Elem, <1, =) 

Sorts: Elem, List; 

Functions: nil List; . : Elem, List ^ List; 

car : List Elem; cdr : List List; 

Relations: =: List, List, < : Elem, Elem, = : Elem, Elem; 

Axioms; Va : List \/x : Elem(-nnil = x. a) ; 

Va, (5 : List Vx, y : Elem(x.a = y . (3 ^ x = y f\ a = (3)\ 

Va : List(nil ^ a); 

\/a,(3 List Mx, y : Elem(a; <1 y f\ a < (5^x .a ^ i/./3); 

\/a,(5 List Mx, y : Elem(^a; <1 y^-^x.a ^ 1/./9); 
cdr(nil) = nil; Va : List \/x : Elem(cdr(a; . a) = a); 

Va : List Va: : Elem(-ia = nil^ car(a:.a) = x); 

H*(nil)A'ia : List Vx : E\em{H* (a)^ H* {x .a))^ya : List 
Constraints: Vx, y : Elem(x <\ y f\y <\ x ^ x=y)-, 

Vx, y, z : Elem(x <l y Ay <l z^x <1 z)\ 

Vx, y : Elem(x <1 i/ V y <1 x V x=y); 

Here, the constraints define the parametric relation symbol <1 as a total 
order over Elem and the internal axioms on ^ define it as a total order 
over List. 



We endow closed frameworks with isoinitial semantics. Here we only 
recall that a model X (in the usual classical sense) of a theory T is isoinitial 
iff, for any model A4 of T, there exists a unique isomorphic embedding 
Ip : 2 ^ J\A. Moreover, a model of T is reachable if any element of its 
domain is denoted by a closed term of the language. A detailed discussion 
about isoinitial semantics, its relation with ADT’s specification, and its 
interaction with constructive proof-theory can be found in Here 
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we only remark that isoinitial models meet the usual conditions required 
for ADT, as e.g. uniqueness up to isomorphisms. 

Definition 1 A closed framework is adequate iff it has a reaehahle isoini- 
tial model X. 

The main property of adequate closed frameworks is that they completely 
define the intended meaning of the symbols of their signatures. Indeed it 
is possible to prove that, \i T = (A, T) is an adequate closed framework, 
and X is the related isoinitial model, then, for any ground literal L in the 
language £y;, T|-^L iff T ^ L; where T|-^L means that L is provable 
from T using classical logic and X \= L means that L holds in X according 
to the usual classical interpretation. 

Adequacy of open frameworks is based on the notion of instantiation. 
An instantiation of an open framework J-{P) with the closed framework 
A = (A', T') is the closed framework 

P{P :: A) = (A' U T' U 



where: 

1. IS a signature morphism between the parametric symbols of A(P) 
and A' such that, for any constraint A of T(P), T’\-^^{A). 

2. The signature is obtained by substituting the parametric symbols of 
T(P) with their “implementation” in the framework A (through the 
signature morphism ^). Here A/) indicates the set of non-parametric 
symbols of A(P). 

3. The theory is obtained by replacing the constraints of T(P) with the 
axioms of A and translating the internal axioms of T(P) in the new 
language. 

Definition 2 An open framework P{P) is adequate iff, for every ade- 
quate closed framework A, P{P :: A) is an adequate closed framework. 

General results about closed and open frameworks and sufficient condi- 
tions to guarantee a closed (or open) framework to be adequate are given 

in 13 . 

3 Specifications 

Adequate open and closed frameworks constitute the contexts in which 
we write specifications. Hence, let P{P) = (A(P),T(P)) be an adequate 
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open (possibly closed) framework, and let Iso(^(P)) be a class containing, 
for any closed instantiation !F{P :: of an isoinitial model of 

P{P :: ,A). Moreover, let k\(x) be a finite (possibly empty) set of wff’s 
over Pe{p) with free variables in x, which is intended to represent the 
set of preconditions. The specifications over P{P) and their meanings are 
defined as follows: 

1. Assign := A{x) =^<C 3ziIj{x, z) S> 

For every 2 G Iso(^(P)), it expresses the task of computingMor every 
n-tuple a of the appropriate sorts in 2 such that 2 ^ Z\(x/ aB a value 
b such that 2 ^ 

2. Test-Disjunction :=A{x) V V’ 2 (®)] 

For every 2 G Iso(^(P)), it expresses the task of deciding, for every 
n-tuple a of the appropriate sorts in 2 such that 2 ^ A{x/a), if either 
2 \= tpiix/a) or T ^ tp 2 {x/a) holds. 

3. Assign-Disjunction :=A(x) [3z*ipi{x, z*) V 3z*'il^2{x, z*)] 

For every 2 G Iso(jT(P)), it expresses two distinct tasks: 

(a) Decide, for every n-tuple a of the appropriate sorts in 2 such that 
2 \= A{x/a), whether 2 \= 3zil^i{x/a, z) or 2 \= 3zip2{x/a, z). 

(b) For every n-tuple a of the appropriate sorts in 2 such that 2 ^ 
A{x/a), if X ^ 3zipi{x/ a, z) , compute a value b such that 2 ^ 
i^iixla, zib), otherwise, if X ^ 3zil^2{x/a, z), compute a value b 
such that X |= 'ip 2 {x/a, z/b). 

4. True-Fun :=A{x) ^ [3z*ip{x, z*)] 

For every X G Iso(X'(P)), it expresses two distinct tasks: 

(a) Decide, for every n-tuple a of the appropriate sorts in X such that 
X \= A{x/a), the truth value of the predicate 3zip{x/a, z)] 

(b) For every n-tuple a of the appropriate sorts in X such that X |= 
A{x/a) and X \= 3z'ifj{x/a, z), compute a value b such that X \= 
i^{x/a, z/b). 

We remark that function and relation symbols occurring in the specifica- 
tions are interpreted according to the “intended” classical models of the 
open framework, while the meaning of the logical constants occurring in 
it is not the classical one. 

As an example, let us consider the specification \3z*{z ■ z = x)] in 
the context of the framework PA (the standard model of arithmetic is 
an isoinitial model of PA, and hence this framework is adequate). This 

^ This means that X \= A{x/g3 for any wff A(x) G ‘A(x). 

^ For the sake of simplicity here we identify an element of the model with the term in 
canonical form denoting it in the language. 
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specification expresses, according to the above interpretation, the task of 
deciding whether x is a perfect square or not, and in the former case it 
also express the task of computing the square root of x. Of course, the 
only fact that a meaningful specification can be written does not imply 
that the corresponding task can be performed. But, if we are able to 
exhibit a proof of a suitable wff associated with the specification in a 
constructive formal system, then we are guaranteed on the computability 
of the specification. 

To give a complete account, we recall that a formal system T + L 
(where T is a theory and L is a deductive apparatus) is constructive if 
the following properties hold: 

1. If T\-^A V B with Av B a closed wff, then either or 

2. If T\^3xA{x) with 3xA{x) a closed wff, then there exists a closed 

term t of the language such that T|-Y^(t). 

The wff associated with the specification \3z*{z ■ z = x)] is 3z{z ■ z = 
x) V -Az{z ■ z = x), and its classical truth is a trivial matter. On the 
other hand, if we have a proof of this wff in a constructive formal system, 
e.g., in intuitionistic arithmetic PA + INT (where INT is any calculus 
for first-order intuitionistic logic), then we are guaranteed that, for any 
closed instance of the specification with a closed term t, either 3z{z-z = t) 
or ~^3z{z- z = t) is provable in PA -|- INT. Since PA -|- INT is recursively 
axiomatizable and constructive, by a well known result (see e.g. |3), we 
have, at least in principle, a mechanical way to fulfill the decision task 
involved in the specification. Similarly, constructivity guarantees that if 
3z{z ■ z = t) is provable then also {if ■ t' = t) is provable in the theory 
PA -|- INT for some closed term t' . 

4 Active Proof Patterns and synthesis rules 

In this section we present the method of dischargeable sets. Here we do 
not discuss in detail the theoretical basis of the method, but we will be 
concerned on the way resulting proofs can be translated into programs, 
trying to put into evidence the computational contents of some logical 
and mathematical principles. 

Let us consider an adequate closed framework fF = (L7, T) with isoini- 
tial model T, and a specification of the kind A(x) ^ \3z*'if>{x, z)] (an 
analogous discussion can be made for the other specifications described 
in Section^ . The first step in finding an algorithm to solve a specification 
amounts to assume that it can be solved; formally this corresponds to the 
assumption that the related computability wff 
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f\ A{x) (3z'0(x, z) V -<3zip{x, 

is provable in a constructive formal system T + L (where L is a deductive 
apparatus including intuitionistic logic with identity INT). 

The computability of the specification implies that the set of all pos- 
sible elements a satisfying A(x) in the isoinitial model 2 can be divided 
into two sets; namely: 

1. The set of all a satisfying the preconditions Z\(x) such that 
2 \= 3zip{x/a, z)] 

2. The set D~ of all a satisfying the preconditions Z\(x) such that 
2 ^ -^3zip{x/ a, z). 

Now, let us suppose that D~^ and D~ can be expressed by some appropri- 
ate sets of wff’s, called t-wff’s, i.e., let us suppose that there exist n -|- m 
sets of wff’s (®); • • ■ 5 and 2^ {x), • • • , 2~{x) such that: 

(FI) a G D+ iff there exists r^{x) {I < i < n) such that 2 \= r^{x/a)] 
(F2) a G D~ iff there exists 2~{x) (1 < j < m) such that 2 \= r~{x/a). 

Moreover, let us suppose that: 

(F3) For 1 < i < n, for an appropriate term 

(F4) For 1 < j <m, A{x), 2~ {x)\-^^^3z'il;{x, z). 

If we are able to satisfy conditions (F1)-(F4), then we have “reduced” the 
problem of solving the specification to the problem of deciding, given 
a possible input a satisfying the preconditions 4\(x), which is among 
, • • • , 2^{x/q) and {x/a), ■ ■ ■ , 2^{x/g^ the one satisfied in 
the isoinitial model. Obviously, the problem has been “reduced” if the 
wff’s occurring in these sets are “simpler” than the wff representing the 
specification. As a matter of fact, in this case the method can be iterated 
and can be applied to the wff’s occurring in such sets. Thus, if the family 
of sets {r^ {x ), . . . , F+(x), 2^{x ), . . . , 2~{x)} is dischargeable (according 
to the formal definition given in Appendix0l, then we can translate the 
sequence of facts (F3) and (F4) into a program. 

For instance, let us consider the specification [3z* x<z<y] in the frame- 
work PA expressing the task of deciding whether x<y or not and in the 
former case of finding a z such that x<z<y. The set of all input pairs {x, y) 
can be divided into three disjoint sets, identified by the following sets of 
wff’s: 

r+ = {x<y, ~^x=y} Ff = {x=y} 2^ = {^x<y} 



^ A ‘^{2) represents the conjunction of the wff’s belonging to A{x) 
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Moreover, if L is any deductive apparatus including intuitionistic logic 
with identity, it is possible to prove the following facts: 



F+ 


x<s{x)<y 


(4.1) 






(4.2) 


^2 




(4.3) 



Thus, the problem of solving the specification \^z*x<z<y\ has been trans- 
formed into the problem of deciding whether either x<y and ~^x=y (in 
which case x<y holds and z = x + 1) or x=y (in which case ^x<y holds) 
or ~^x<y (in which case ~^x<y holds). 




'tp{x,y) = (x<s(x)<y) V ~<x<y 



Fig. 1. 



The sets of wff’s = {x<y, ~'X=y}, Ff = {x=y}, and Fi^ = {^x<y} 
are an example of dischargeable set w.r.t. ip{x, y) = (x < s{x)<y) V ~^x<y. 
Moreover, according to the theory of dischargeable sets (see Theorem^^, 
the proofs of Facts ^3, ^3, and (^3 can be arranged (using the 
natural deduction formalism) in the proof of FigureH We remark that 
this proof only uses the rules for the connective V and the quantifier 
3. This corresponds to the fact that in our approach the latter are the 
logical rules with a proper eomputational eontent and that they determine 
an active pattern (a more detailed discussion can be found in Q). 

Moreover, the proof of Figure 0™akes explicit the relation between 
Facts ^3~^9 process of computing the specification. If we are 
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able to decide the outermost test Ti, then we can accordingly consider 
one of the inner subproofs Si and 82- If x = y holds then we consider Si 
and this immediately gives the result ~^x<y. On the other hand, if -ix = y 
holds then we consider ^2; at this point, if we are able to decide the test 
T2, we can continue the computation following either S^ or 54 . The latter 
gives the result ~^x<y, while the subproof S3 give the result x < s(x)<y 
and the relation 2: = s(x) between the input and the output variables. 

Thus, having found the dischargeable set, we have “reduced” the prob- 
lem of solving the specification [ 3 z* x<z<y] to the problem of solving 
the specifications [x=y] and [x<y]. Moreover, the above proof suggests 
in which way the corresponding sub-programs must be arranged in a 
program of the original specification. The proof of the above example is 
translated into the following peace of program, where we use a PASCAL- 
like programming language containing the usual structures if-then-else, 
while-do-end, repeat-until, case and the composition 

if x=y then 
tv:= false 

else if x<y then begin 
z\=x+V, 
t^r■.—true 
end 
else 

tv:= false; 

Here the boolean variable tv stores the truth-value of the wff x<y. 

We remark that, solving the specification according to the above (in- 
formal) strategy, we do not need the proofs of Facts indeed 

these subproofs correspond to correctness patterns. According to the pre- 
vious remark, we could use classical logic instead of a constructive logic 
to prove Facts The interaction between constructive and non- 

constructive (classical) proofs can be formally justified in the context of 
a constructive modal logic with a modality representing classical truth 
(see, e.g. Q). 

Finally, we notice that in more complete examples dischargeable sets 
may also contain wff’s, called f-wjf’s, representing functions to be com- 
puted in order to solve the specification; in our top down approach, these 
wff’s are translated into new specifications. For instance, let us consider 
the specification 

Z\(x, v) = { 3 k{v*v = k A x<k)} 

[ 3 z*{ 3 k{z**z* = k A x<k A z*<v)) V 3 z*{z* = ^/x)\ 
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which arises from the top-down analysis of the specification <C 3z(z = 
\/x) ^ we will treat in Section ^3 where represents the integer 
square root of x. 

In this case, the set of all input pairs (x, v) can be divided into two 
disjoint sets, identified by the sets of wff’s -T’*' = {x<m*m, m=v-l} and 
r~ = m=v-l}, depending on the function f{v) = v-\. More- 

over, the following facts hold: 

A[x, n), r~^\ ^^ 3k{m*m = k A x<k A m<v) 

A{x, v),r~\ p" = V® 

Hence, we obtain the following program: 

m=v-l\ 

if (x<m*m) then begin 
2 := m; 
tv := false 
end 

else begin 
z := m- 
tv := true 
end 



5 Induction Principles 

The dischargeable sets we have considered in the previous section coincide 
with proofs in T -|- L in which the active patterns connected with the con- 
nective V and the quantifier 3 have been separated from the correctness 
patterns. But, as one should expect, in a general framework a proof of the 
computability wff related to a specification uses some induction principles. 
Here we will study the active patterns corresponding to the application of 
two induction rules we call Tail Recursion and Descending Chain, 
which naturally arise in the context of several ADT’s. 

5.1 The Tail Recursion Principle 

Tail Recursion is a particular kind of recursion where the recursive proce- 
dure call is the last instruction of the calling program. As it is well known, 
this kind of recursion can be unfolded into an iterative program. Here we 
present a (pseudo)-natural deduction rule, we call TR, whcih can be seen 
as the deductive counterpart of Tail Recursion, and we give the iterative 
program schema for this rule. 

First of all we state the conditions that an open framework must 
satisfy for the TR principle to be valid in the corresponding theory. 
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The principle TR is valid in the context of a given framework J-{P) = 
(r(P),T(P))if: 

(Cl) Let s be the sort on which the induction works. Then, there exist a 
function f : s, si, . . . , Sh ^ s and a finite set {ci, . . . , Cm} of constants 
of sort s in P{P) such that, for any t : s, there exists a s-f-canonical 
term t' : s such that t = t' \s provable in T + L. Where the set of 
s-f-canonical terms is inductively defined as follows: 

- Every constant in {ci, . . . , Cm\ is a s-f-canonical term; 

- If t" is a s-f-canonical term and : si, . . . are closed terms, 

then f{t", ti, ... ,th) is a s-f-canonical term. 

(C 2 ) There exist function symbols g : s ^ s, gi : s ^ si, . . . , gh ■ s ^ Sh 
in P{P) which are axiomatized as the inverse functions of /. 

In the case of a specification of the kind L\(x) ■ ■ -Xn, 2;)| with 

x\ the induction variable, the Tail Recursion Principle has the following 
form: 



^(£),a ^{x),rk 

• 7Tl • TTfc 

■>P{f{w,y),x^,z)^ ... ip{f{w,y),X 2 ,z)^ 

TR 

■ ■ ,X„,z)V -^tpixi,- ■■ ,Xn, z) 

where X2 is X2, . . .,Xn and y is yi, . . . , yh- Moreover, 'tp{x, z) denotes the 
wff • • • , Xn, z) V ->^|^{xl, • • • , Xn, z) and y),X2, z)^ is either 

y),X2, z) or y),X2, z). Finally, the proofs vri, . . . , vr^ must 

satisfy the following conditions: 

(PI) For each 1 < i < A:, if 'tp{w,X2, z) belongs to T), then vrj is a proof of 
ip{f{w, y),X2, z), while if ~^'ip{w,X2, z) belongs to Pi, then vr* is a proof 
of ~^il;{f{w,y),X2^z). 

(P 2 ) The set {P \, . . . , Py} is dischargeable w.r.t. y), X2, z). 

The program schema corresponding to the above rule is the iterative 
version of a recursive call by Tail Recursion given in Figure H In this 
figure, x\ is the recursion variable, Pci > Pc2 ) ' ' ' ) are the sub-programs 
corresponding to the base cases and g, g\, . . . , gy are the implementations 
of the functions of point (C 2 ). Finally, if P is the program obtained by 

The TR rule can be reformulated also for the other specifications described in Sec- 



A{x) 



A{x) 



TTci ■ '^cm 

i’{ci,X2,z) ... il{Cm,X2,z) 
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ExCond:=false; 
repeat 
case xi in 

ci: begin 

Po^-, ExCond:=true 
end; 

C2'. begin 

Pc 2 -, ExCond:=true 
end; 



Cm:begin 

Pcm i ExCond:=true 
end; 

otherwise 

begin 

yi:=gi{xi)-, 



yh--=gh{xi)-, 

p*. 



end 

until ExCond; 



Fig. 2. Program schema for TR 



the dischargeable set {Fi, . . .Ffc}, then P* is obtained by transforming P 
according to the following rules: 

(Rl) Every piece of program of P of the form: 

if ®2i then . . . 

gjgg IS removed 

(R2) Every piece of program of P of the form: 

tv:=true . tv:=true 

w:=f{w,y) is replaced by Excond:=tme 

(R3) Every piece of program of P of the form: 

tv:=false 

tv-false is replaced by Excond:=tme 

The previous rule TR and the corresponding program schema can 
be generalized to the case of simultaneous induction on several variables 
as shown in the following example. (For a discussion on such kinds of 
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induction rules we refer the reader to |3-) Let us consider the frame- 
work List(Elem, <1, =); this framework satisfies conditions (Cl) and (C2), 
indeed: 

1. Every list a can be constructed using the constant nil and the func- 
tion . : Elem, List— > List; 

2. cdr(x.a) = a and car(x.a) = x. 

Now, let us consider the specification [a ■< (3] expressing the task of de- 
ciding whether the list a is less than or equal to the list (3. We can prove 
the related computability wff using the TR rule as follows: 



X <\ y 



^x<\y, -^x-^y, 

^x <\ y, ~'X=y x=y , ^ p x=y ,a < p 



• 7Tl , ^ • 7T3 • 7T4 • 7T5 * 7T6 

nil ^ d a ^ nil x.a<y.p ~^{x.a<y.p) ~^{x.a <y.p) x.a<y.p 

TR 

a < p\/ -la ^ p 



where proofs vri-TTg can be easily constructed. The corresponding program 
is given in FigureH 

We notice that the program of Figure H depends on the implemen- 
tation of the procedures for deciding the parametric binary relations <1 
and = defined over the sort Elem. Now, the theory of frameworks guar- 
antees that in every closed instantiation of the adequate open framework 
LIST(Elem, <l, =) these relations are indeed decidable. Therefore, if we in- 
stantiate the framework LIST(Elem, <l, =) with a closed framework where 
these procedures have already been implemented, we are assured on the 
correctness of the resulting instantiated program. 



5.2 Descending Chain Principle 

The Descending Chain Principle has been studied in the context of ADT’s 
and program synthesis ^3^3- Here we describe this principle applied to 
a specification of the kind z) ». Also in this case, the 

principle can be applied to the other specifications defined in Section H 
The DCH rule is: 



■hfe) A(x), [A(£,y)]i 

• 7Tl ' 7T2 

3«A(2:,x) 3z{A{x, z) a z ^ y) y 3zij}{x, z) 



'b(®, z.) 



DCH,1 
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ExCond:=false; 
repeat 
case a in 

nil: begin 

Pr, 



ExCond:=true 

end; 

otherwise begin 
case f3 in 

nil: begin 

Pr, 

ExCond:=true 

end; 

otherwise begin 
a:=cdr(a); 

/3:=cdr(/3); 
a;:=car(a); 
j/:=car(/3); 
if X <\y then begin 
tv:=true; 

ExCond:=true 

end 

else if not (x= y) then begin 
tv:=false; 
ExCond:=true 
end; 

end; 



end 

until ExCond; 



Fig. 3. 



where y (the parameter of the rule) does not occur free in "ip and in the 
other undischarged assumptions of the proof tt2. 

For the principle to be valid, the framework J-{P) must satisfy the 
following condition: 

(C) The relation symbol ^ must be interpreted in any model of Iso(^ {P ) ) 
as a well founded order relation. 

y) is called the DCP-wff. This induction principle corresponds 
to a repeat-until loop where the exit condition is given by the DCH-wff 
A{x, z). The repeat-until loop computes a decreasing sequence of values 
(with respect to -<) approximating the solution; the solution is reached 
at the end of the cycle. Hence, the program schema corresponding to the 
DCH rule is: 
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Pi\ 

repeat 

P2-, 

until (not tv); 

where Pi and P 2 are the sub-programs obtained by translating the proofs 
TTi and 7T2 respectively, and tv is the boolean variable storing the truth 
value of the DCH-wff. 

In many cases, the DCH-wff is closely connected with the computabil- 
ity wff related to the specification and, if the computability wff represents 
a function, then the DCH-wff represents a function approximating the de- 
sired solution. 

As an example, let us consider the specification <C 3z{z = ^/x) 3> 
in the framework PA expressing the task of computing, for each natural 
number x, its integer square root. 

A possible approximation of the solution could be the following one: 
for each x G N compute a 2 ; G N such that x -< z*z. Thus, let A{x, z, i) = 
z*z=i A x<i, then, using 3kA{x, v, k) as the DCH-wff, we get: 

[3k {v ■ V = k A X < k)]i 

• 7Tl ■ 7T2 

3z3y {z ■ z = y A X < y) 3z{3k {z ■ z = k A x < k A z < v))V 3z{z = y/x) 

DCH,1 

3z(z = \/x) 

Since the proof vri simply corresponds to the assignment 2 ; := x+i, and 
the proof 7T2 can be translated into the program at the end of Section B 
the program obtained for the specification <C 3z(z = is: 

z:=x+l; 

repeat 
m := z-1; 

if (x<m*m) then begin 
z := m; 
tv true 
end 

else begin 
2 := m; 
tv false 
end 

until not(tv); 



6 Conclusions and future works 

In this paper we have presented a synthesis method based on the notion of 
discheargeable set allowing to distinguish active patterns from correctness 
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patterns and we have showed how some of these patterns can be translated 
into an imperative language. Moreover, we have discussed how the method 
can be used to synthesize programs in ADT’s and in classes of ADT’s. In 
the last case we obtain parametric programs which can be reused in any 
ADT of the class. 

Concerning our future work, we aim to implement the proof method 
of dischargeable sets construction and the related synthesis mechanism 
inside the logical framework Isabelle. For this purpose we are devel- 
oping proof schemata for driving the construction of the proof in a top- 
down way, implementing a given algorithmic strategy (as, e.g., divide-et- 
impera). This implies a research on the correspondence between logical 
rules and algorithmic strategies. 

From a theoretical point of view we are also investigating some con- 
structive modal logics (with a modal operator representing classical truth) 
allowing to combine in a single formal framework constructive proofs, re- 
quired for the construction of active patterns, with classical subproofs, 
sufficient for the construction of correctness patterns. 
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A Dischargeable sets 

Let r and F' be two finite and non-empty sets of wff’s and let A and 
B be two wff’s; we say that F and F' are conjugated w.r.t. A and B iff 
either A £ F and B £ F' oi B £ F and A £ F' . [F, F']a^b will denote the 
fact that F and F' are conjugated w.r.t. A and B. 

Given I = {Fi , . . . , Fn} where any Fi is a finite and non-empty set of 
wff’s, and given to wff’s A and B, we say that F £ X occurs conjugated 
in X w.r.t. A and B iff there exists F' £X such that [i^, F'\a,b- 

Definition A1 Let X = {/^i, . . . , Fn\ he such that any Ft is a finite and 
not empty set of wff’s, let A and B be two wff’s, and let F £ X be any 
set occurring conjugated inX w.r.t. A and B. Then a discharging set of 
X generated by F w.r.t. A and B is any set X^^ defined as follows: 

1. if A = B, then 

(a) for every j (1 < j < n), if Fj F, then Fj £ 

(b) if {F \ {yl}) ^ 0 then {F \ {yl}) G X^^^. 

2. Otherwise: 

(a) Fj £ X^Q for every j (1 < j < n) such that Fj F and [/^, Fj]A,B 
is not satisfied; 

(b) Let S be a non-empty subset of all the F such that [F,F]a,b is 
satisfied (possibly the set of all such F is selected). For every F £ 
S, if {F U F) \ {A, B} 7 ^ 0, then {FU F) \ {yl, B} belongs to X^ ^ . 
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Obviously, according to different choices of the set S in point (2b), we 
obtain different sets 

Definition A2 Let X = {/^i, . . . , -T^} such that every Xi is a finite 
and not empty set of wff’s. Let A be a finite (possibly empty) set of wff’s, 
let and 4> be two wff’s, and let T + L, be any formal system. We say 
that X is a Z\t/;0-dischargeable set fin T + Lj iff one of the following 
conditions is satisfied: 

1. X is empty; 

2. There exist -Tj G X, S’ C (Uj=i n \ wjf’s A and B 

such that 

(a) X' = X, U S, 

(b) X' = (X\{XJ)U{X'}, 

V B, 

(d) r' occurs conjugated inX' w.r.t. A and B, 

r-il 

(e) there is a setX which is Afxf-dischargeable. 

3. There are Xj G X fl < i < n), S C (Uj=i n^j \ {^^^})> ® 

A{x) such that 

(a) X' = X, U S, 

(b) X' = (X\{XJ)U{X'}, 

(c) r' occurs conjugated inX' w.r.t. A{x) and A{x), 

(d) for all B G T' , if B ^ A then x is not a free variable of B, 

(e) x is not a free variable of any wff in A, of and of 4>, 

(f) A{z), and 

(g) the set is Afifi-dischargeable. 

By the previous definition, if X is a non empty Z\'0(f>-dischargeable set, 
there exist a set X, two wff’s A and B and a set X' = X^^ which is 
Z\tf(f)-dischargeable; again, if X' is not empty, there exist a set X', two 
wff’s A' and B' and a set X” = X'^i which is Z\^f0-dischargeable; and 
so on. Therefore, associated with a non empty Z\'0 0-dischargeable set X, 
there is a non empty sequence of wff’s ({Ai, B\}, . . . , {An, Bn}), we call 
discharging sequence ofX. 

As an example, let A, B, C(x), 4> and be wff’s such that x does 
not occur free in and B; moreover, let us suppose that V ~^A, 

tp\-^B V -iX, and (fi\-^^zC{z). Then, the set 

X = {{-X}, {A, X}, {A, C{x),B}, {-A}} , 

is an example of 0^f-i^f-dischargeable set. As a matter of fact, X generates 
the discharging set 

r' = A®] ={{A],{A, C{x)}. {-A}) , 
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X' generates 

r = 1'^A^A = , 

and X" generates the empty set 

Now, hereafter, we will call dis-adequate (shorthand for dischargeable- 
adequate) any wff 4>{x, z) of the kind 3yi . . . 3ym4>'{x, z,y±, . . . , ym) with 
m > 0 such that cj)' is not an existential wff. We call cj)' the immediate 
subformula related to 4>. 

Definition A3 Let A be a finite (possibly empty) set of wff’s and let 
(f}{x,z) and fi{x,z) be two dis-adequate wff’s. A Aficf-dischargeable set 
X = {Xi, . . . , is said to be Z\-dischargeable with respect to fiV 4> (in 
T -I- Lj iff, for every Fi E 1, either A, Fi\-;^ilj' , or Z\, where 

and fi' are the immediate subformulas related to fi and fi respectively. 

The connection between formal systems and Z\-dischargeable sets w.r.t. 
fiWfiis stated by the following theorems. 

Theorem A4 Let A a finite set of wff’s, and let fi and fi be two dis- 
adequate wff’s. Moreover, let X = {Xi, . . . , X„} be a A-dischargeable set 
w.r.t. fiW fi (in F -\-T). Then fi- 

We remark that the proof of the above theorem (given in full detail in 
B) implicitly contains an algorithm to construct a proof of V fi 

given a A^'0-dischargeable set. 

Obviously, given a solvable specification, the problem of building a 
dischargeable set for it is not trivial, and is as difficult as to write the 
desired program. 
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Abstract. Current Object-oriented Design (OOD) methodologies tend 
to focus on objects as the unit of reuse, but it is increasingly recognised 
that frameworks, or groups of interacting objects, are a better unit of 
reuse. Thus, in next-generation Component-based Development (CBD) 
methodologies, we can expect components to be frameworks rather than 
objects. In this paper, we describe a preliminary attempt at a formal 
semantics for OOD frameworks in CBD in computational logic. 



1 Introduction 

Most of the existing (semi-formal) Object-oriented Design (OOD) methods such 
as Fusion and Syntropy B use classes or objects as the basic unit of design 
or reuse. These methods are based on the traditional view of an object, as shown 
in Figure H which regards an object as a closed entity with one fixed role. 



visible 

functions 



encapsulated 

internal 

structure 



Fig. 1. Traditional view of an object. 



This, however, does not reflect the nature of objects (and classes that describe 
them) in practical systems. In particular, objects tend to have more than one 
role in more than one context or framework. Consequently, it is increasingly 
recognised that classes are not the best focus for design (see e.g. Typical 

design artefacts are rarely just about one object, but about groups of objects 
and the way they interact. 

Therefore in the next generation of component-based development (CBD) 
methodologies, we can expect components to be not just objects, but groups of 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 101-^^1999. 

(c) Springer-Verlag Berlin Heidelberg 1999 



102 Kung-Kiu Lau and Mario Ornaghi 



(interacting) objects. In the CBD methodology Catalysis for example, 

objects can have multiple roles in different OOD frameworks, and are formed by 
composing frameworks, as depicted in Figure 



^ Framework 1 



^ Framework 2 



role A 




role B 




Fig. 2. Objects by composing OOD frameworks. 



In computational logic, we have formulated a formal approach to program 
development in which we use what we call specification frameworks to 

formalise problem domains. These frameworks have purely declarative (model- 
theoretic) semantics. In this paper we will show (how) we can extend such frame- 
works to make them correspond to OOD frameworks. The latter are groups of 
(interacting) objects with local states. Our extension thus has to introduce states 
and hence objects. However, in the paper we will not address temporal aspects 
such as state transitions. 



2 Overview of Our Approach to Program Development 



Our approach to program development in computational logic is based on a 
three-tier formalism (with model-theoretic semantics) illustrated in Figure^ 



Framework:- T 



Specification:- speci 


Specification:- spec 2 | 


Specification 1 


Specification 2 




Program:- progi 


1 Program:- prog 2 


Program 1 


Program 2 



Fig. 3. A three-tier formalism. 
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At the top level, we have specification frameworks (or frameworks for short)| 
A framework is a first-order theory that axiomatises a problem domain. Model- 
theoretic semantics for frameworks is based on isoinitial models. 

In the middle, we have specifications. Specifications are always given in the 
context of a framework. A specification is a set of formulas that define a new 
relation or function symbol in terms of the symbols of the framework. 

At the bottom level are (correct) programs. For every specified relation r, a 
framework may contain a correct program for computing r. We have a model- 
theoretic definition of correctness, based on steadfastness 

Frameworks may be parametric, thus supporting classes, subclasses, inheri- 
tance, and framework composition. In particular, a composite framework inherits 
all the properties, specifications and correct programs of its components; correct- 
ness is preserved by framework composition, and the inherited programs can be 
composed to yield new correct (composed) programs. Thus, frameworks capture 
the declarative semantics of reusable components needed by CBD methodologies, 
and of their correctness and their composition 

However, so far our frameworks are static, i.e. they are immutable theories. In 
this paper, we will introduce states into our frameworks, and we will show that 
we thus obtain a formalism suitable for next-generation CBD: in particular, our 
approach provides a formalisation of OOD frameworks and their composition. 

3 Specification Frameworks 

Specification frameworks are defined in the context of many sorted first-order 
logic with identity. In this section we introduce and formalise such frameworks. 
We will attempt to give a self-contained treatment, because our existing for- 
malisation of frameworks does not contain or emphasise the key aspects that 
are required for introducing states and objects. So we wish to hereby warn the 
reader about the somewhat heavy, formal material that lies ahead. 

We begin by recalling some relevant terminology and notation. 

A many-sorted first-order signature S consists of a set S of sort symbols, a 
set F of function declarations and a set R of relation declarations. A function 
declaration is of the form f : [a] ^ s, where / is a function symbol, [a] is its aritjJ 
and s is its sort. Function symbols of empty arity are called constant symbols. 
A relation declaration is of the form r : [a] , where r is a relation symbol and [a] 
is its arity. 

The meaning of the symbols of a signature E is given by E -structures (or 
E -interpretations). As usual, the meaning of a sort symbol s in a strucWre i 
is a set, called the domain of s, while function and relation declaration^ are 
interpreted in i as functions and relations. The meaning of a (declaration of a) 
symbol a in a structure i will be denoted by a'. 

^ To avoid confusion, we will always use frameworks to refer to specification frameworks 
only. OOD frameworks will always be called OOD frameworks. 

^ [a] is a list of sort symbols. 

® We interpret declarations, in order to allow overloading. 
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A i7-structure i is reachable if, for every sort symbol s of if and every element 
a of the domain s', there is a ground term t such that valj{t) = a, where valj{t) 
is the value of t in the interpretation i, and is recursively defined in the usual 
way. 

For a set Ax of if-sentences, i |= Ax means that every sentence of Ax is true 
in i. If i 1= Ax, then i is called a model of Ax. 

In first-order logic with identity, overloaded identity =; (s, s) (for every sort 
s) is always understood, and =; (s, s) is interpreted, in every interpretation 
i, as the identity over s'. Moreover, the standard identity axioms are always 
understood. 

In this context, a framework T = (if, Ax) is composed of a signature if and 
a finite or recursive set Ax of if-axioms. 

The purpose of a framework is to axiomatise a problem domain and to reason 
about it, with the help of an interactive theorem prover. In our approach, a 
problem domain contains the ADT’s and classes needed to define the objects of 
the application at hand. 

We distinguish between closed and open frameworks. The relationship be- 
tween open and closed frameworks plays a crucial role in our interpretation of 
objects. Roughly speaking, in object-oriented programming terminology, open 
frameworks represent classes, and closed frameworks represent their instances, 
i.e. objects. 

3.1 Closed Frameworks 

In a closed framework T = (if, Ax) the purpose of the axioms Ax is to ‘com- 
pletely’ characterise the meaning of the symbols in the signature if. This can 
be achieved by singling out an intended model i of Ax. We will use reachable 
isoinitial models as intended models. 

Definition 1 (Isoinitial Models). Let Ax be a set of if-axioms. A if-structure 
i is an isoinitial model of Ax iff, for every other model m of Ax, there is one 
isomorphic embedding f : i ^ m. 

Definition 2 (Closed Fhameworks). A framework T = {E,Ax) is closed iff 
there is a reachable isoinitial model i of Ax, called the intended model of Ax. 

Thus, our closed frameworks are isoinitial theories, namely theories with 
reachable isoinitial models. They are similar to initial theories, which axiomatise 
reachable initial models. The latter are popular in algebraic abstract data types 
and specifications The difference is that initial models use homomorphisms, 
instead of isomorphic embeddings. We briefly discuss some relevant consequences 
here (for a more detailed comparison, see Q). 

Let Ax be a set of If-axioms with a reachable model i, and consider the 
following properties: 

(i) For every ground atom A, i ^ A iff Ax h A. 

(ii) For every ground literal L, i |= if iff Ax h L. 

(iii) For every ground atom A, Ax h A or Ax I — <A. 
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i is an initial model of Ax if and only if (i) holds, while i is an isoinitial model 
of Ax if and only if (ii) holds. Thus, in an initial theory the falsity of a ground 
atom A corresponds to the non-provability of A, while in isoinitial theories it 
corresponds to the provability of ~^A. That is, isoinitial theories behave more 
properly, with respect to negation. 

Since negation is important for reasoning about specification and correctness, 
we have chosen isoinitial theories. A second reason for this choice is that condi- 
tion (ii) can be replaced by condition (iii), called atomic completeness. This is 
a purely proof-theoretical condition, i.e., i |= . . . disappears. This makes it more 
manageable. For example, we have used it to link isoinitiality to termination 
of logic programs Q, and in a constructive proof-theory for isoinitiality 
has been based on atomic completeness. A third reason lies in our distinction 
between closed and open frameworks. Closed frameworks are required to be rich 
enough, to have an intended model. If such a model does not exist, then they 
are open. If we use initial theories, this distinction becomes very weak, as shown 
by the following example. 

Example 1. Consider a framework for natural numbers, of the form: 

Framework NAT ; 

SORTS: Nat] 

DECLS: 0 : [ ] ^ Nat] 

s : [Nat] Nat] 

AXIOMS: Ax] 

where, as we pointed out before, = and its standard axioms are understood. 

NAT is a closed initial framework, even for an empty set of axioms (i.e., 
with Ax = 0). Indeed, the Herbrand Universe 7f(0, s) generated by {0, s} is a 
reachable initial model of 0. This shows that very weak frameworks are accepted 
as being closed. In particular, in such frameworks we cannot prove negated facts, 
like, in this example, -'s(O) = s(s(0)). 

By contrast, to get an isoinitial theory axiomatising ?-f(0,s), we need the 
following /reeness axioms for {0, s}: 

Ax = {Vx . ^0 = s(a:), Vx, y . s(x) = s(y) x = y} 

These state that different ground terms represent different numbers, i.e., the 
framework works properly with respect to negation. 

A framework with an isoinitial model can be constructed incrementally, by 
adequate expansions, namely expansions by new symbols S, that preserve the 
meaning of the old signature: 

Definition 3 (Adequate Expansions of Closed Frameworks). T' = {E + 

6, AxU Ds) is an adequate expansion oi T = {N Ax) if T' is a closed framework 
and its isoinitial model is a (U -f- (5)-expansioi| of that of T . 



^ As usual, a (E + 5)-expansion of a X'-interpretation i is a (X -f <5)-interpretation i' 
that coincides with i over X. 
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In an expansion, the axioms Ds are called a definition of 5. A definition 
is adequate iff the corresponding expansion is. Adequate definitions are a very 
useful tool for incremental construction of frameworks, starting from a small 
kernel. There are various kinds of adequate definitions. 

Example 2. We can expand the kernel NAT of natural numbers by useful func- 
tions and/or predicates. For example, the following is an adequate expansion of 
NAT. 



Framework PA; 

IMPORT: NAT ; 

NEW: -1- : [nats, Nat] - 


Nat; 


WHERE a; -h 0 = a; 


* : [nats, Nat] - 


Nat; 


a:-h s(t/) = s(a:-h 2 /) 
WHERE a: * 0 = 0 


1 ■. [] -^ Nat; 




X * s{y) = X * y + X 
WHERE 1 = s(0) 


< : [Nat, Nat]; 




WHERE x<y->^3z.x+z = y 



All the new symbols are introduced by adequate definitions: -I- and * by (ade- 
quate) recursive definitions, and 1 and < by (adequate) explicit definitions. 

Of course, we need methods for proving the adequacy of a definition. Let us 
briefly consider this issue for explicit definitions, which suffice for our purposes. 
In a framework T = {E.,Ax), explicit definitions have the following general 
forms: 

— An explicit definition of a new relation r is a (A -(- r)-formula of the form 
Vx . r(x) R(x) where the defining formula R{x) is a A-formula. 

— An explicit definition of a new function / is a (A -1- /)-formula of the form 
\/x . F{x, f{x)) where the defining formula F{x, y) is a A-formula such that 
Ax h 'dx3\y . F{x, y). 

In ^3 we have shown how adequate explicit definitions can be established by 
means of programs synthesis. In it is shown that constructive proof-systems 
can be used to prove adequacy. For this paper, it suffices to know that if the 
defining formula is quantifier- free, then an explicit definition is always adequate. 

3.2 Open Frameworks 

An open framework does not have an isoinitial model, since its axioms leave 
open the meaning of some symbols of the signature, that we call open symbols. 
Non-open symbols will be called defined symbols. 

We denote an open framework by T{^) = (S,Ax) where 17 are the open 
symbols. Since 17 may contain open sorts, we consider l7-reachable models, where 
17-reachability is reachabiliW in an expansion containing a new constant for each 
element of each open sortj Moreover, we require that the axioms be sufficient 

® We do not worry about the cardinality of the new constants. 
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to characterise the meaning of the defined symbols, in terms of the open ones. 
This corresponds to adequacy, which, for open frameworks, can be introduced 
as follows. 

Definition 4 (f7-equivalence). Let T{fi) = {E,Ax) be an open framework, 
and let i and be two models of Ax. We say that i and are 17-equivalent if, 
for every open symbol ct € 17, ct' = ct' . 

17-equivalence is an equivalence relation. Therefore it partitions the class of 
models of T{Q) = {S,Ax) into ^-equivalence classes, or fl-classes for short. 
In an 17-class, we will consider l7-isomorphic embeddings, i.e., isomorphic em- 
beddings that behave as the identity function over the (possible) open sorts. 
l7-isoinitial models are defined like isoinitial models, but they use l7-isomorphic 
embeddings instead of isomorphic embeddings. 

Definitions (Adequate Open Frameworks). 1F(17) = {E,Ax) is an ad- 
equate open framework if and only if every 17-class contains an l7-reachable 
l7-isoinitial model. 

Thus an adequate open framework axiomatises a class of intended models, 
namely the l7-isoinitial models contained in the 17-classes. An l7-isoinitial model 
j of an 17-class represents the intended meaning of the defined symbols, when the 
open symbols are interpreted as in j itself. We say that j is an intended model of 
the open framework. Since the framework is open, we have many non-isomorphic 
intended models. 

Example 3. The following example is trivial, but it serves to explain ideas and 
problems simply and clearly. 

Ftamework TTZIV{X, q); 

SORTS: X, s; 

DECLS: j : [X] s; 

q:[X,X]; 

AXIOMS: j{x) = j{y) —> X = y 
p{x) ^ 3y. q{x,y)-, 

Let us interpret, for example, X as the term structure {0, s(0), s(s(0)), . . .} of the 
natural numbers, and q{x, y) as the predicate x > y. We get the interpretation 
{j(0), j(s(0)), j(s(s(0))), . . .} of s and x ^ 0 of p{x). Indeed, this interpretation 
is an A-reachable isoinitial model in the {X, ( 7 )-class interpreting X and q as 
before, i.e., it is an intended model. 

We can prove that, if a framework T{Q) is adequate, then, for every intended 
model j, there is a suitable closed expansion of T{fi) that axiomatises it. The 
new axioms of such an expansion essentially coincide with all the l7-formulas 
that are true in the interpretation of the parameters. However, since we need 
axiomatisations that can be managed by a theorem prover, the problem is to 
state which axioms are needed to get the desired closed instances. 
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Example 4- Consider the framework TTZTV{X, q) of Example^ To fix an in- 
terpretation of the open symbols X and q, a completion procedure has to add 
a closed set Axnew of new axioms, whose isoinitial model corresponds to that 
interpretation. Furthermore, the new axioms must satisfy the following require- 
ment: 



for every ground t, Axnew h . q{t, y) or Axnew h “'dy . q{t, y) (1) 
which ensures atomic completeness for the defined symbol p. 

In this example, condition Q guarantees that the new axioms complete 
the open framework into a closed one. Conditions of this kind will be called 
constraints. We have the following situation: 

An open framework explicitly contains its constraints (if any), and a 
completion procedure is a procedure to add axioms that satisfy the con- 
straints. By a completion procedure, we can build many closed expan- 
sions, that we call instances. 

Also, adequate open frameworks can be built incrementally, starting from a 
small, well understood kernel, and defining new symbols by adequate defini- 
tions, namely definitions that are inherited in a sound way (for more details, see 

The existence of many instances implies reusability, every theorem, expan- 
sion, specification or correct program developed in an open framework are in- 
herited, and can be reused in all its instances. Reusability was an important 
motivation behind open frameworks and has been used in to treat paramet- 
ric frameworks. In this paper, we will also use them to define objects with states. 
To this end, we introduce a completion procedure based on explicit definitions. 

We shall assume that we start with an open framework that already contains 
a closed subframework Q, i.e., is of the form iF{f2) Q. This assumption is not 
restrictive, since it suffices to import Q in lA(i7). We can use Q to close the 
meaning of the open relations and functions, as follows: 

— Sort closure. The operation: 



CLOSE A BY S 

renames the open sort A by a sort s of the closed subframework Q. This 
operation generates the framework + Q, where is obtained by 

renaming A by s in .F(l7). 

— Relation closure. The operation: 

CLOSE r BY Va; . r(x) ^ R{x) 

defines the meaning of an open relation r{x) by a formula R{x) of the closed 
subframework Q. We require that the declaration of r contains only sorts of 
Q, and Va; . r{x) <-> R{x) is an adequate explicit definition of r in the closed 
framework Q. 
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— Function closure. The operation: 

CLOSE / BY Wx.F{x,f{x)) 

defines the meaning of an open function f{x) by a formula F{x,y) of the 
closed subframework Q. We require that the declaration of / contains only 
sorts of Q, and Va; . F{x, f{x)) is an adequate explicit definition of / in Q. 

To close all the open symbols of an open framework tF{f2) by a closed frame- 
work Q, we can start from tF{f2) + Q and proceed as follows: 

(i) Close the open sorts, and obtain a framework tF'{fi') + Q, where, in the open 

part all the open sorts of tF{f2) have been renamed by closed sorts 

oig. 

(ii) Then close the relation and function symbols, and obtain a framework 
tF'{n') -I- g', where g' is the (adequate) expansion of g by the explicit defi- 
nitions used to close the open relations and functions. 

We can prove the following theorem (we omit the proof, for conciseness) . 

Theorem 1. Let be an adequate open framework and g be a closed frame- 

work. Let tF' {(!') + g' be the final result of steps (i) and (ii) above. Lf g' satisfies 
the (possible) constraints of then tF' {f2')-\-g' is an adequate expansion of 

g' and its isoinitial model is an isoinitial model of the fi' -clas^that interprets 
FI' as the isoinitial model of g' . 

That is, the closed instance of iF'{F2') + g' is an adequate expansion of g, and 
its intended model is defined according to tF'{F2'). Indeed, it coincides with the 
intended model of tF'{F2') that interprets the sorts of F2' according to g, and the 
functions and relations of F2' according to the explicit definitions used to close 
them. 

Example 5. We can close TTZTV{X, q) as follows: 

IN TTZIV{X, q) : 

IMPORT VA] 

CLOSE: X BY Nat] 

q BY Vj/ . q{x, y) ^ y < X. 

The result is the following closed framework: 

Fhamework TTZTV{Nat, q) -h VA' 

IMPORT VA] 

SORTS: S] 

DECLS: 7 : INat] s; 

p : [Nat]] 
q : [Nat, Nat]] 

AXIOMS: q{x, y) ^ y < X 

j{x) = j(y) ^ x = y 
p{x) 3y. q{x,y)] 

® is an adequate open framework, since it is a renaming of F{F2). 
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VA! is the expansion of VA by the explicit definition q{x, y) ^ y < x, used to 
close q. According to VA', Nat is interpreted as the set {0, s(0), s(s(0)), . . .} of 
natural numbers, and q{x,y) as y < x. The corresponding intended model of 
TTZIV{Nat,q) interprets s as {j(0), j(s(0)), j(s(s(0))), . . .} and p{x) as a; 0 
(see Example ^ . The same interpretation is given by the isoinitial model of 
TTZIV{Nat,q) + VA' , i.e., TTZIV{Nat,q) + VA' is an adequate expansion of 
VA! , where the interpretation of p and s is that defined by TV.IV{N at, q), when 
the parameters are interpreted according to VA' . 

To conclude this section, we remark that Example ^corresponds to param- 
eter passing which replaces X by Nat and q hy <. The only difference is that 
both q and < are in the final signature! That is, our closure operations can 
be used to implement parameter passing. On the other hand, our mechanism is 
more general, since we could close open relations and functions by any kind of 
adequate, possibly recursive, definitions. 



4 Classes and Objects 

In the previous section we have presented the foundations for (specification) 
frameworks. In this section, we will show that these frameworks can be used to 
model both classes and objects in the terminology of object-oriented program- 
ming. 

We shall use only frameworks that are adequate: frameworks that represent 
ADTs are called ADT- frameworks, and those that represent classes and objects 
are called OBJ-frameworks, respectively. 



4.1 ADT- frameworks 



A closed ADT-framework is a closed framework T that axiomatises an abstract 
data type (ADT). For example, the closed framework VA is a closed ADT- 
framework. It axiomatises the data type of natural numbers. 

An open ADT-framework is an open framework that axiomatises a 

class of intended ADT’s. The intended ADT’s are the intended models oi 
as defined in the previous section. 

The instances of an open ADT-framework can be built by closing the open 
symbols in the way explained in the previous section. Once an instance is ob- 
tained, it is and remains static, i.e., ADT’s cannot evolve. 



Example 6. The following is the kernel of an adequate (open) framework of lists: 



^ However, by eliminability of explicit definitions, we could eliminate q if we wanted. 
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ADT-Ftamework CIST{X, <) 
import: VA] 



SORTS: 


X, List; 




DECLS: 


nil : [ ] — ^ List; 






: [X, List] List; 






nocc : [X, List] Nat; 
elemi : [List, N at, X]; 






< ■{X,X); 




AXIOMS: 


free{nil , .); 
nocc{x, nil) = 0; 

a = b ^ nocc{a, b.L) = s{nocc{a, L)); 
~^a — b ^ nocc{a, b.L) = nocc{a, L); 
elemi{L, i,a) ^ 3x : X . 3N : List . 3j 


: Nat. 




(f = 0 A T = a.N) V (f = s{j) A L = 


x.N A elemi{N,j, a)) 


CONSTRS: 


TotOrd<i. 





where the abbreviations free{nil, ■) and TotOrd<\ stand, respectively, for the 
freeness axioms of nil and •, and the total ordering axioms for the open symbol 

O. 

The axioms characterise the defined symbols List, nil, ■, nocc and elemi in 
terms of the open ones, while the constraints are used to constrain the open 
symbol <1 to be a total ordering. 

Once we have fixed an interpretation of the open symbol X, we get the 
structure of finite lists with elements in X. If, in this structure, we interpret <1 
as a total ordering, then we get an A-reachable isoinitial model in the class of 
models of CIST{X, <) that have the same interpretation of X and O. 



4.2 OBJ-frameworks 

A OBJ-framework is also an adequate open framework Its closed instances 

can be built in the way explained in the previous section. An OBJ-framework 
lF(f7) will also be called a class, and its instances will be called objects of that 
class. The axioms used to close iF{f2) into an object represent the state of the 
object, and are called state axioms. State axioms can be updated, i.e. an object 
is a dynamic entity. 

When an object is created, the symbols of the signature of the class may 
be renamed, so that different objects have different signatures. We will use the 
following convention: 

— The signature of an OBJ-framework may contain dotted symbols, namely 
symbols whose names begin with a dot. 

— Each object has a name, and different names represent different objects. 
When creating a new object with name n, dotted symbols are renamed 
by prefixing their names with n. Therefore, the signatures of two different 
objects will contain different dotted symbols. Dotted symbols are used for 
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dynamic symbols, whose axioms and meaning may evolve in different ways 
for different objects. 

— Non-dotted symbols are left unchanged. They are used for the static ADT- 
parts of the OBJ-framework (typically imported from pre-defined ADT- 
frameworks) that will be the same in all objects. For example, the ADT 
of natural numbers is always the same, in any object that uses it. 

In an OBJ-framework dotted symbols are dynamic. Therefore they 

must be open, and as such we do not need to list them as open symbols, i.e., 
we can write T instead of This reffects the different uses ADT and OBJ- 

frameworks are intended for. In the former, the open symbols act as parameters, 
that can be closed by external closed frameworks, giving rise to immutable closed 
ADT-frameworks. In the latter, dynamic symbols act as a state. They can be 
dynamically closed within the framework itself, giving rise to dynamic objects. 

Example 7. An OBJ-framework for car objects could be: 

OBJ-Ftamework CATZ{.km, .option); 
import: lUT, year96; 

DECLS: .km : [ ] ^ Int 

.option : [year96.opts] 

CONSTRS: .km > 0 

where INT is a predefined ADT of integers, and year96 is an object that con- 
tains the sort year96.opts of the possible options for a car in the year 96. 

An object of class CATZ is created, for example, by: 

NEW .spider : CATZ; 

CLOSE: .spider.km BY spider.km = 25000; 

spider. option by spider. option{x) <-> a: = Airbag V x = AirCond. 

where spider.km = 25000 is the explicit definition that closes the constant 
spider.km, while spider. option{x) <-> a: = Airbag V x = AirCond is the explicit 
definition that closes the predicate spider. option{x). 

The state of a spider object can be updated, by redefining its state axioms: 

UPDATE spider : CATZ; 
spider.km = 27000 

spider. option{x) <-> a: = Airbag V x = AirCond 
As we can see, the constant spider.km has been changed. 

When creating and updating objects, we have to guarantee that the explicit 
definitions used to close the open symbols are adequate, and that the constraints 
are satisfied. The former condition is automatically satisfied if we use quantifier- 
free defining formulas. The latter condition, in general, requires a proof. Since 
proofs are typically time consuming, it is better to design methods for the whole 
class that guarantee constraint satisfaction. 
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Example 8. In the previous example, we have used quantifier-free defining for- 
mulas. Therefore, adequacy is guaranteed. Methods for the class CATZ, that are 
guaranteed to satisfy the constraints are: 



create{k, yi, . . yj-) : — fc > 0, assert{.km = k), 
assertiy x{.optio{x) ^ x = yi V . . .V x = yk)- 

kmupdate(x) : — x > .km, replace{{.km = K), (.km = a;)). 

where replace(A, B) is defined by retract(A) .assert(B) . In the creation method 
create, the constraint .km > 0 follows from fc > 0. In the updating method 
kmupdate, the new values for .km are required to be greater that the old ones. 
Since the latter already satisfy the constraint, we are all right. 

Note that here the syntax is not relevant. We have not yet fully formalised the 
dynamic aspects such as state transition (see the discussion in the conclusion). 
The above examples give only an idea. 

5 OOD Frameworks 

Having introduced classes and objects in the previous section, in this section 
we show how we can define OOD frameworks as frameworks containing com- 
posite objects, i.e. as composite OBJ-frameworks. We shall do so by formalising 
composite objects as systems of objects. We then show that our composite OBJ- 
frameworks indeed correspond to OOD frameworks as used in CBD methodolo- 
gies like Catalysis. 



5.1 Systems of Objects 

To introduce systems of objects, we need the notion of multiple instance of a set 
0\, . . . , On of OBJ-frameworks. 

Definition 6 (Multiple Instances). Let 0\, . . . , On be a set of OBJ-frame- 
works, and ai, . . . ,ak be instances of them| A multiple instance {ui, . . . , Ofc} 
is defined as the union (of the signatures and of the axioms) of all the single 
instances ai,l < i < k. 

To give a semantics of multiple instances, we need a link between the isoinitial 
models of the individual instances aj,l < j < n, and the isoinitial model of the 
multiple instance. 

Definition 7 (Additivity and Strong Additivity). A set of adequate OBJ- 
frameworks is additive if its multiple instances {oi, . . . , Ofc} satisfy the following 
properties: 

(i) If each aj, I < j < n satisfies the constraints, then {oi, . . . , Ofc} is a closed 
framework. 



Each OBJ-framework may have 0, 1 or more instances. 
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(ii) Let i be the isoinitial modejof {ai,...,afc}. For every j, 1 < j < k, the 

isoinitial model \j of aj is isomorphically embedded into the reduct of i to 

the signature of Uj . 

It is a strongly additive set of OBJ-frameworks if, in (ii), the isoinitial model \j 
of Uj is isomorphic to the reduct of i to the signature of aj . 

We have the following theorem: 

Theorem 2 (Representativity) . Let {oi, . . . , Ofc} be a multiple instance of a 
set Oi, . . . , On of adequate OBJ-frameworks. 

If Oi^ ... ^On is strongly additive, then every sentence of the language of 
Oj ) 1 ^ j < k, is true in its isoinitial model if and only if it is true in the 
isoinitial model of the multiple instance. 

If 0\, . . ., On is additive, then every quantifier-free sentence of the language 
of o,j,l < j < k, is true in its isoinitial model if and only if it is true in the 
isoinitial model of the multiple instance. 

In a multiple instance {oi, . . . , Ufc}, the formulas of the language of an indi- 
vidual instance Uj correspond to the properties that are ‘locally observable’ in 
Qj, while the formulas of the (larger) language of the multiple instance represent 
properties that are ‘globally observable’. 

Strong additivity entails that the truth of any locally observable sentence is 
preserved in the global multiple instance. Additivity guarantees to preserve only 
those local properties that can be expressed by quantifier- free sentences. 

Additivity is sufficient to prove the following proposition: 

Proposition 1. If a set of OBJ-frameworks is additive, then we can update a 
multiple instance, by adding, deleting or updating groups of individual instances, 
without altering the isoinitial models of the other individual instances. 

This guarantees that we can confine our updates to a part of a set of co- 
operating objects, without undesired side-effects on the other parts. Additivity 
suffices for our purposes. As we will see, there are cases where strong additivity 
is too restrictive. 

Now, we can introduce the notion of a system of objects. Composite OBJ- 
frameworks will be based on such systems. 

A system of cooperating objects S[0\, . . . ,Orf\, based on an additive set 
Oi, ... , On of adequate OBJ-frameworks, is an object whose state, at any time 
t, is characterised by a multiple instance of Oi, . . . , On, and (possibly) by other 
dynamic symbols, defined at the system level. 

The methods for changing the state of S[Oi, . . .,On] are the methods for 
creating new instances of a class Oj G {Oi , . . . , On} and deleting or updating an 
already existing individual object. Since Oi, . . ., On is additive, these operations 
update the global state of the system, without altering the isoinitial models of 
the untouched individual objects. 

® i is unique up to isomorphism. 
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There are various ways of defining system methods. For example, they may 
be based on messages, as in many object-oriented programming languages. A 
possibility that we are investigating is introducing a meta-level where time is 
made explicit, and where system methods become logic programs. This formal- 
isation is in its infancy and will not be presented here. Nevertheless, regardless 
of how system methods are formalised, it is clear that, at every time t, a system 
has the following properties: 

— 5[Oi, . . .,On] has dynamic signatures and axioms. At each time t, it ‘con- 
tains’ a multiple instance of C>i, . . . , 0„. It has a global signature Ssys{t) 
and a global set of axioms Axsys{t), and each individual instance Oj has its 
own signature Sj{t) and axioms Axj{t). 

— Since the system is a multiple instance, for each individual instance aj in it, 
Sj{t) is a subsignature of Ssys{t), and Axj{t) is the restriction of Ax.sys{t) 
to the signature Sj{t). Moreover, in Esys{t), we can distinguish a static and 
a dynamic part. 

— The static part consists of the signature and the axioms of the (closed) ADT’s 
included in the OBJ-frameworks Oi,. . On- This part is, globally, a closed 
ADT. We will denote it by ADTsys- 

— The dynamic part contains the dotted symbols and the axioms that have 
been used to close them in the various individual objects contained in the 
system at time t. Beside the dotted symbols, a system may contain non- 
dotted dynamic symbols, together with the related closing axioms. Non- 
dotted dynamic symbols are useful for expressing dynamic properties that 
are common to groups of objects and, hence, are not to be renamed (in 
contrast to dotted symbols which always are). In particular, there may be 
non-dotted system symbols, whose axioms are managed at the system level, 
i.e., outside the constituent OBJ-frameworks. 

The presence of non-dotted dynamic symbols may affect additivity, so they 
must be treated with some care. The following proposition states a sufficient 
condition for strong additivity: 

Proposition 2. Let 5[0i,...,0„] be a system of objects. If all the dynamic 
symbols are dotted, then the system is strongly additive. 

If there are dynamic non-dotted symbols, then strong additivity and additiv- 
ity may not hold. However, there are interesting cases where at least additivity 
is guaranteed. For example, if we have a non-dotted dynamic sort s, and s is 
closed, in each individual instance, by the freeness axioms of a set of constant 
symbols, then additivity is guaranteed. 

We may also organise the objects of a system into sub-groups, so that we 
isolate properties that are common to a subgroup, but are not visible by the 
objects of another subgroup. This, of course, requires us to introduce a suitable 
renaming policy, e.g., by allowing multiple dottings, like path-names of a system 
with a tree-structure. We do not discuss this issue here, although our theoretical 
foundations are strong enough to embrace it. 
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Considering the possibility of non-dotted system symbols, a very useful tool 
is introducing the names of the individual objects (or of groups of objects, in 
a more complex renaming structure) in the signature. To this end, we assume 
that every system . . .,OnJ has itself a reserved name sys and its global 

signature always contains a system reserved sort symbol obj and system re- 
served predicates Oi, . . . , 0„. We require that the following system constraint is 
preserved by the methods for creating and destroying objects. 

At each time t, the isoinitial model \{t) is such that: 

(i) is the set of names of the objects contained in the system at 
time t. 

(ii) i(t) 1= Oj{n) if and only if n is the name of an individual object of 
class Oj, contained in the system at time t. 

Once we haw the names of the objects, we can also introduce expressive 
axiom schemas^Jas shown by the following example: 

Example 9. Suppose we want to define a predicate .id : [obj], such that, in every 
object with name n, n.id{x) holds if and only if x is the name of the object itself, 
i.e., X = n. We write down the axiom schema: 

#N.id{n) ^n = #N 

where the meta-symbol jfN stands for any object name. So, if ted is an object- 
name, we get the instance ted.idin) <-» n = ted. 

Now, we can introduce composite objects. 



5.2 Composite Objects 

A composite object is like a system 5[C>i, . . . , 0„], but now the additional global 
signature does not contain the symbols sys, obj, . . ., that we have introduced in 
a system framework. It contains other (in general dotted) symbols, that are open 
symbols of the composite object not already contained in the components. Apart 
from this, we can reason exactly as we have done for systems of objects. 

Example 1 0. Let us assume that we are working in a system containing at least 
the following OBJ-frameworks: 

OB J-Ftamework CATi ; 
import: . . .; 

DECLS: .weight : ^ int 

.km : — > int 
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As usual, an axiom schema is a template for a given general form of axioms. 
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OBJ-Ftamework VETZSOAf ; 

IMPORT . . 

DECLS: .name : string; 

.age : int; . . . 

CONSTRS: .age > 0 

We want to compose them into a driver framework, where a driver is a person 
allowed to drive a non-empty set of cars. We can set up a composite framework 
like 

OBJ-Pramework VTZIV£TZ[V£TZSOAf,CATZ\; 

DECLS: .drives : [obj]; 

CONSTRS: #X.drives{c) ^ PERSON{#X) A #X.age > 18 A CAR{e); 

(3c : obj){.drives{c)); 

SPEC: ^X. Driver Component{n) ^ n = ^X V ^X.drives{n); 

PROG: ^X.Component{N) : — N = #X; =ffX.drives{N). 

Note that we are in the context of a system framework, and the system 
language, i.e., the sort obj and the predicates PERSON, CAR, DRIVER,. . ., 
can be used in the OBJ-frameworks of the system framework. 

In the framework 'DRIVER., we have also shown an example of a specification 
and a corresponding correct progranQ (or method) . As we said, specifications 
and correct programs may be part of an open or closed framework, and hence 
of OBJ-frameworks. 

Here the composite object states links on its components, constraining cre- 
ation and deletion methods. We cannot create an object n.DRIVER, if n is not 
a person. Furthermore, we need at least one car c. Thus, a method for creating 
a DRIVER object will be of the form: 

#X.ereate{#Ci, ..., #Ck) : - not#X.error{#Ci, ..., #Ck), 
add{#X, state{jfX .drives{e) ^ c = #Ci V . . . V c = #Cfc)). 

#Xerror(#Ci,...,#Cfc) :- 

^{PERSON{#X), CAR{#Ci), ..., CAR{#Ck)) 

where error displays appropriate error messages, and programs for add, PER- 
SON, CAR are defined at the system level. PERSON[X) fails if X is not a 
constant of sort obj, or if it is not the name of a RERSOJV-ohject contained in 
the system. CAR is similarly defined, add updates the state-axiom closing obj, 
includes the signature of the ^A-instance of DRIVER, and adds the state- 
axioms state {. . .). 

Complementary methods for deleting cars and persons will be of the form: 

jj^X. delete : — notjf X. error, eancel{jfX). 

#X.error : - DRIVER{#N),#N.Component{#X). 

In this example we will use a PROLOG-like formalism, but our discussion is inde- 
pendent of the chosen language. 
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where, similar to add and cancel can be defined at the system level. Note that the 
predicate .Component is needed in deletion methods of components of composite 
objects. We can assume that each composite OBJ-frameworks has to specify, at 
least, its own predicate .Component, as well as a correct method for computing 
it. 



As we can see from the example, we can specify methods like .C omponent(X) , 
and we can reason about their synthesis and correctness in the usual way in our 
approach to program development. In contrast, in our previous work we have 
never specified methods for creating, deleting or updating objects. This is be- 
cause we do not have a language to formally specify them; as a consequence, we 
can speak about their correctness only informally. A formal system specification 
language should contain appropriate system symbols, and making time explicit 
seems to us very useful. We are studying these aspects. A short discussion will 
be given in the conclusions. 

Finally, we briefly show that composite OBJ-frameworks are OOD frame- 
works as used in CBD methodologies like Catalysis. First, the composite OBJ- 
framework VTZTVSTZ can be represented in Catalysis by the simple (closed) 
OOD framework shown in Figure^^jHere the person object is fixed (and so is 



Driver 



Fig. 4. The Driver OOD framework. 



the composite driver object), like the traditional object in FigureJ 

A more interesting example is one where an object is formed by composing 
OBJ-frameworks in each of which the object plays a different role. 

Example 11. In the OBJ-framework 'DTZ'IV£Ti[V£TZSOJ\f ,CATZ], the role of a 
person is to drive a car. So we can rename the Driver OOD framework in Figure 
Qas the PersonAsDriver OOD framework. 

Equally a person could also be a guest at a motel, i.e., we can build an OBJ- 
framework QU£ST\P£TZSOJ\f ,MOT£C]. Thus a person can play the roles of 
driver and guest respectively in the PersonAsDriver and PersonAsGuest OOD 
frameworks, as shown in Figure B Then we can compose the two frameworks 
into 'DTZIV£Tl + QU£ST\P£TiSOJ\f ,CATZ,MOT£C], where a person has two 
roles. This is depicted by Figure^ In PersonAsDriverGuest, a person object is 
a composite object of the kind depicted in Figure 2. 

Finally, we briefly discuss open OBJ-frameworks. In the previous example, both 
VTZIV£TZ and QU£ST have the general structure of an user, i.e., they have 
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We will present a simplified version of the (UML-like) notation used in Catalysis. 
More details can be found in 
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PersonAsDriver 

^<drives 
I Car I 



Person 



PersonAsGnast 



Fig. 5. PersonAsDriver and PersonAsGuest OOD frameworks. 




Fig. 6. PersonAsDriverGuest OOD framework. 



the form < lASETZ > [< USIAfQ >,< USET> >]. Here we have open OBJ- 
frameworks (indicated by the presence of the parameters < USING > and 
< USET> >), which cannot close their (possible) dynamic symbols by themselves. 

In general, open OBJ-frameworks need to incorporate more knowledge, to 
become OBJ-frameworks of the kind we have considered here, where dynamic 
symbols can be closed without any additional knowledge. We have not treated 
open OBJ-frameworks here for lack of space. They would allow us to model open 
OOD frameworks as used in Catalysis. 



6 Conclusion 

We have presented semantic foundations for OOD frameworks as used in current 
GBD methodologies, in particular Catalysis. Our three-tier formalism makes 
explicit the existence of two levels of reuse. The first level of reuse occurs at 
the (top) level of specification frameworks. Here reuse is based on the classical 
inheritance mechanisms and is governed by constraints. The second level of reuse 
occurs at the levels of specifications and programs. Here reuse is governed by 
specifications, which indicate how to correctly compose open correct programs, 
to get new correct (composite) programs. The second level of reuse thus pertains 
to correct program reuse, which, we believe, contributes to a better understanding 
of and support for reusability in OOD and GBD. We have already studied correct 
program reuse within ADT’s, through the notion of steadfastness. The next step 
is to extend our study to state transitions, by formalising the dynamics of object 
systems. 

We have also a model-theoretic, i.e. declarative, semantics. Our semantics 
is model-theoretic and hence declarative. Such a semantics is important we be- 
lieve for defining, and reasoning about, the key elements of next-generation GDB 
methodologies, and should provide a sound theoretical basis for their implemen- 
tations. As an example, our use of isoinitial theories (and models) is motivated 
by our desire for a good declarative semantics; but we do not expect ordinary 
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users to handle such theories, which should be well-hidden in CBD implemen- 
tations. Rather, users will reason in terms of the intended interpretations of the 
symbols of the ADT’s, classes and objects that they use. We believe that the se- 
mantics classical first-order logic, based on classes of interpretations that satisfy 
common properties, models in a natural and intuitive way the variety of uses 
and meanings that open ADT’s and classes can assume in different contexts. 

Our approach is similar to that proposed by Maibaum in the use of 
theories as the units of construction and the relevant role of conservative (and, 
in our approach, adequate) extensions. However, we have a different empha- 
sis on intended models. The introduction of errors is most likely during the 
phase of specification design, and we believe that a clear declarative semantics 
is very important and helpful to reduce the risks of mistakes at this level. An- 
other difference is that our modularity is ruled by framework constraints, rather 
than guaranteed by general conditions, like interpolability. Moreover, we want 
to model correct reusability of open programs, rather than stepwise implemen- 
tation. Nevertheless, refinement based on mediating theories is interesting, as 
also shown by SPEC WARE and it seems that it could be imported in our 

approach, as an orthogonal technique. 

Our model-theoretic characterisation of states and objects stands in contrast 
to the type-theoretic approach by Abadi & Cardelli Q, however. 

The work that is most closely related to ours is that of Bourdeau & Cheng 
Q, which formalises a semantics for object model diagrams in OMT Ba- 
sically they translate object model diagrams into algebraic specifications (and 
semantics) expressed in Larch Thus they use initial theories, as opposed to 
isoinitial theories that we use. Our preference for isoinitial semantics has already 
been discussed in Section^ Another motivation is that, using initial semantics, 
additivity entails only that positive locally observable quantifier-free sentences 
are preserved at the system-level, i.e., any problems with negation will affect 
additivity. 

Moreover, the formalisation proposed by B is not oriented to (open) OOD 
frameworks, i.e. groups of interacting objects. In other words, they consider 
objects as the unit of reuse, whereas our formalisation supports OOD frameworks 
as the unit of reuse. As we pointed out before, industry is increasingly recognising 
that objects are not the best focus for design, and OOD frameworks are becoming 
widely used as the basic unit of reuse. 

Other approaches to formal semantics for CBD methodologies are mainly 
so-called integrated methods. For example France et al Q derives Z spec- 
ifications from Fusion diagrams. At present, such methods do not have 
completely formal semantics. 

So far, our semantics provides a sound formalisation of OOD frameworks 
used in the CBD methodology Catalysis. However, in order to implement these 
frameworks, we need a formalism to describe and specify state transitions. In 
our semantics, we have only states at particular instants, i.e., each object has 
an intended model only at a fixed time, and we can treat state transition in a 
limited way. We can deal with the problem of constraint satisfaction, but not 
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with the global system behaviour. More precisely, we cannot specify temporal 
properties, like liveness or deadlock freeness. 

In order to achieve this capability, we are studying a temporal model for 
systems of objects. After a first attempt, inspired by evolving algebras Q|, we 
decided to model states by evolving axioms. At each time, an evolving axiom A 
represents an observable instantaneous property. Evolving axioms are not so far 
from dynamic attributes (as used in, e.g., Q and TROLL For example, a 
dynamic attribute a : int with (current) value 5 corresponds to the (evolving) 
axiom a = 5, but evolving axioms allow us to describe larger classes of attributes, 
including data bases. To express dynamic behaviour, we need to model actions 
and time, taking into account the modularity induced by the presence of com- 
posite objects (similar ideas can be found, e.g., in ^J). Our aim is to introduce 
time in the specification language, and to deal with correctness of state transition 
methods in this extended context. 
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Abstract. Most modern computing systems consist of large numbers 
of software components that interact with each other. Correspondingly, 
the capability of re-using and composing existing software components 
is of primary importance in this scenario. In this paper we analyse the 
role of renaming as a key ingredient of component-based programming. 
More precisely, a meta-level renaming operation is introduced in the con- 
text of a logic-based program composition setting which features a num- 
ber of other composition operations over general logic programs, that 
is, logic programs possibly containing negative premises. Several exam- 
ples are presented to illustrate the increased knowledge representation 
capabilities of logic programming for non-monotonic reasoning. The se- 
mantics of programs and program compositions is defined in terms of 
three- valued logic by extending the three- valued semantics for logic pro- 
grams proposed by Fitting A computational interpretation of pro- 
gram compositions is formalised by means of an equivalence preserving 
transformation of arbitrary program compositions into standard general 
programs. 



1 Introduction and Motivations 

Most modern computing systems consist of large numbers of software compo- 
nents that interact with each other. Correspondingly, the process of software 
development is changing from writing large pieces of software in some program- 
ming language to writing small pieces of software in some (meta-)language to 
suitably “glue” existing components and put them at work together. 

Our work aims at contributing to setting firm foundations for developing 
program composition methodologies. We investigate the issues of program com- 
position in a setting where both the language of components and the meta- 
language for composing them have a formal mathematical semantics. More pre- 
cisely, we choose logic-based programming for specifying the components and a 
set of meta-level composition operations on logic programs as the gluing (part of 
the) meta-language. In previous work we have proposed the use of a basic 
set of meta-level operations on logic programs for mastering the complexity of 
designing complex systems. More precisely, we have considered a modular ap- 
proach to software development, where a complex system is partitioned into a 
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number of small pieces that are designed to be combined together via composi- 
tion operations. 

In this paper, the role of renaming as a key ingredient for component-based 
programming is analysed. The capability of renaming symbols is indeed of pri- 
mary importance in a program composition setting. On the one hand, inde- 
pendently developed components may employ different vocabularies of symbols. 
Different components may use different names for the same procedure, or may 
instead denote different procedures by the same name. These problems typi- 
cally arise when building complex systems by combining large numbers of pre- 
existing components. In these situations, the capability of renaming symbols to 
eliminate vocabulary differences is a powerful support for the reuse of existing 
software components. On the other hand, renaming can be also employed to 
implement forms of information hiding and import /export among modules. In- 
tuitively speaking, (part of) the code of a component may be made hidden to 
other components by renaming its symbols into fresh symbols that do not occur 
in any other component. 

To analyse the importance of renaming for component-based programming, 
we will consider renaming as a basic meta-level operation on components, and 
formally define its meaning as a program transformation operation. More pre- 
cisely, we will introduce a renaming operator in the context of the family of 
composition operations presented in Q, and we shall focus our discussion on 
some examples to illustrate the expressive power of renaming. 

The computational interpretation of renaming is defined via an equivalence 
preserving syntactic transformation of general program expressions into standard 
general programs, which can be then executed by any state-of-the-art interpreter 
for logic programs. 

The paper is structured as follows. Section J describes our program com- 
position setting, while Sections Q and Q are devoted to discuss programming 
examples. Section H shows how the three- valued semantics characterisation of 
general programs suitably extends to program compositions, including the re- 
naming operator. Finally, Section ^contains some concluding remarks. 

2 General Program Expressions 

Throughout the paper, we shall use the standard terminology and notation of 
logic programming f. A literal is an atom or its negation, and a (general) query 
is a finite conjunction of literals. A general clause is a clause of the form L 
where A is an atom and A is a query. A general program is a finite set of general 
clauses. Following P, we consider a universal language in which all programs 
and queries are written, and we denote by B the Herbrand base of the language 
and by ground(P) the fully instantiated version of program P. 

We also consider four basic meta-level operations for composing general pro- 
grams: union (U), intersection (n), restriction {-<), and renaming (RN). Starting 
from a collection of named general programs, these operations define the follow- 
ing class of general program expressions: 
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E - P I EUE I EnE I E-<E \ RN{p,E) 

where P is (the name of) a general program. Syntactically, both operands of U, 
n and -< are program expressions. In a renamed expression RN{p, E) the first 
operand is instead a renaming substitution. 

A renaming substitution is defined as a set of pairs {p[/pi, ...,p'Jph} where 
{pi, ...,ph\ and {p'l, disjoint sets of predicate symbols. This first re- 

striction is aimed at avoiding the confusion caused when a symbol plays both 
the role of the renamed symbol and the role of the renaming one, and allows 
idempotence to be enjoyed by renaming. 

Moreover, Vi,j G : {i ^ j => Pi ^ pj). This second restriction is 

obviously required in order to avoid ambiguities. Namely, there should be at 
most one way of renaming each symbol. It is worth observing that the renaming 
p is not forced to be injective. As will be discussed in the sequel, there are 
concrete cases in which we can take advantage of non-injectivity. 

As a third and last constraint, a renaming substitution p = {tt'/tt} is ap- 
plicable to a program expression E if the set of predicate symbols tt' is disjoint 
from the set of predicate symbols occurring in 

Informally speaking, the effect of renaming a program expression E via 
a renaming substitution p — {p'^/pi, ...,p'Jph\ is that every occurrence of a 
predicate symbol Pi in E is replaced by p' in the renamed program expression 
RN{p,E). We will denote by Ap the application of a renaming substitution p 
to an atom A. Similarly, we will denote by Ip and Pp the application of p to a 
set of atoms I and to a program P. Moreover, we will sometimes abuse notation 
and denote a renaming substitution p simply by {tt'/tt}, where tt' and tt are sets 
of predicate symbols. 

Any composition of general programs can be transformed into an equivalent 
general program. Namely, we define a syntactic transformation r that maps any 
general program expression E into a general program t{E) which is equivalent 
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where name{A) denotes the predicate symbol of atom A, and defs{P) denotes 
the set of predicate symbols defined in a program P. 



^ The set of predicate symbols occurring in a program expression E is defined as the 
set of predicate symbols occurring in the program t{E), obtained by applying the 
transformation r (see later) to E. 
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The transformation r merely depends on the syntactic structure of the given 
expression, namely on the composition operations and on the syntax of the 
programs forming it. When the program expression is already a general program 
then r is just the identity function. The union of two programs corresponds to 
the set-theoretic union of the clauses of the separate programs. The intersection 
operation combines two programs by merging pairs of clauses with unifiable 
heads into clauses having the (duplicate-free) conjunctions of the bodies of the 
original clauses as a body. The net effect is that the two programs act as sets of 
constraints one upon the other. Consider for instance the programs 

P: Q: 

Likes(x,y) <- ^ Bitter(y). Likes(Bob.y) <- Sour(y). 

Hates(x,y) <- Sour(y). 

Then the program t{P H Q) = { Likes(Bob,y) ^ ^ Bitter(y), Sour(y). } consists 
of just one clause obtained by joining the first clause of P with the clause of Q. 
Notice that t{P n Q) does not contain a definition for predicate Hates, since the 
latter is not defined in Q. 

The restriction operation filters the set of clauses of a program by eliminating 
all the clauses defining predicates which are defined in another program. Namely, 
r(P -< Q) contains all the clauses of P which define predicates for which no 
definition is present in Q. For instance, in the previous example we have that 
t(P -< Q) = { Hates(x,y) <- Sour(y). }. 

Finally, as far as renaming is concerned, the transformation of an expression 
RN{p, E) is simply obtained by applying the renaming substitution p (applicable 
to E) to the general program t{E). For instance: 

r(PW({Loves/Likes}, (PnQ))) = {Loves(Bob.y) <- ^ Bitter(y), Sour(y). } 



3 Reusing Components 

The ability of renaming symbols is of primary importance when considering the 
problem of combining independently developed components. 

Consider for instance a simple program Graph for determining, via standard 
transitive closure, the existence of a path between two nodes in a directed graph. 
Namely Graph defines a relation Path in terms of an Arc relation over the nodes 
of a graph. Program Graph can be then composed with a program containing 
the representation of an actual graph. For instance, we may wish to use Graph 
with an existing database Trains containing information on train connections 
between cities: 

Graph: Trains: 

Path(x,y) <- Arc(x,y). Train_connection(Florence, Milan). 

Path(x,z) <- Arc(x,y), Path(y,z). Train_connection(Pisa, Florence). 
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The renaming operator can be then exploited for combining Graph with Trains 
so to find the existence of train connections between cities. The example — that 
is over-simplified here because of space limits — is however representative of the 
general situation of a program defining some property (Path in this case) over 
some generic relation (Arc). Such a composition can be obtained by renaming 
predicate Arc into Train_connection by means of the expression: 

i?fV({Train_connection/Arc}, Graph) U Trains. 



It is worth observing furthermore, that renaming may also support the merg- 
ing of different predicates into a single one. Referring to the previous example, 
let us now imagine to have two separate data bases containing information on 
train connections and flight connections between cities. Then, by renaming the 
predicates Train_connection and Flight_connection into Arc and by performing the 
union of the renamed programs with program Graph, it is possible to find out 
the paths connecting two cities and employing at each step either the train or 
the plane. 

This non-injective use of renaming highlights how, in our framework, renam- 
ing is not just a vocabulary switch, but rather a mechanism for changing the 
cooperation degree among separate modules. 

Notice that, in the above examples, the reuse supported by renaming can 
also be achieved by introducing “bridge clauses” to link separate components. 
Namely we may simply consider the expressions 



Graph U Trains U 
and 

Graph U Trains U 



{ Arc(x,y) <- Train_connection(x,y).} 

J Arc(x, y) <- Train_connection(x, y). 
(Arc(x, y) <- Flight_connection(x, y). 



It is worth observing however that, besides the extra derivation step introduced 
by bridge clauses, renaming and bridge clauses are different in essential ways. 
Intuitively speaking, this is due to the fact that renaming changes the meaning 
of a program, while bridge clauses only extend the meaning of a program. 

Consequently, the corresponding behaviours are not equivalent, as the fol- 
lowing example shows. Consider the programs: 



A: B-. 

Likes(Bob,x) <- Positive(x). Likes(Sue.x). 

Likes (Mary, x) <- SportsPerson(x). SportsPerson(Sue). 

Positive(Tina). 

SportsPerson(John). 



Suppose that, by adopting a hypothetical reasoning viewpoint, we wish to com- 
bine A with B while considering Sue as a positive person rather than a sports 
person J 

^ It is worth pointing out here that the original programs are not affected by the use 
of renaming (and neither by the use of the other operators), hence the forms of 
update we realise are to be seen as virtual and hypothetical rather than effective 
(and destructive). 
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Let us now compare the programs PI = t{A U i?7V([Positive/SportsPerson],i3)) 
and P2 = t{A U B U { Positive(x) <- SportsPerson(x) }), resulting respectively 
from the choice of employing renaming and from the choice of employing bridge 
clauses: 



PI: 

Likes(Bob,x) <- Positive(x). 
Likes(Mary, x)<- SportsPerson(x). 
Likes(Sue,x). 

SportsPerson(John). 

Positive(Sue). 

Positive(Tina). 



P2: 

Likes(Bob,x) <- Positive(x). 
Likes(Mary, x)<- SportsPerson(x). 
Likes(Sue,x). 

SportsPerson(John). 

SportsPerson(Sue). 

Positive(Tina). 

Positive(x) <- SportsPerson(x). 



It is easy to observe that the resulting programs PI and P2 are not equivalent 
since Sue is still considered a sports person in P2 and, for instance, we can 
deduce — differently from PI — that Mary likes Sue. 

Finally, renaming can be exploited together with other composition opera- 
tions to define more structured compositions. For instance, consider a database 
Holidays containing general rules for choosing a country for the next trip. Pred- 
icate Good_Place(c,s) is intended to indicate that country c is a good place for a 
visit during season s. 



Holidays: 

Good_Place(c,s) <- 

Dangerous(c,s) <- 

Dangerous(c,_) <- 

Attractive(c,s) <- 

Attractive(c,_) <- 

GiviLWar(Algeria). 
Art_Gountry(ltaly). 
Nat_Beauty(Brasil). 



^ Dangerous(c,s), Attractive(c,s). 
Rainy_Season(c,s). 

GiviLWar(c). 

Hot_Season(c,s), Nat_Beauty(c). 
Art_Gountry(c). 



Imagine also to have a knowledge base Prices containing information on the 
cost of living in foreign countries, and a set Prefs of rules specifying additional 
information on possible preferences. 

Prices: 

Rich_Gountry(Sweden). 

Med_Gountry(Spain). 

Poor_Gountry( Brasil). 
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Prefs: 

Medium(x,s) 

Exclusive(x,s) 

Cheap(x,s) 



<- ^ Rich_Country(x), Med_Season(x,s). 
<- Rich_Country(x), High_Season(x,s). 

<- Poor_Country(x), ^ High_Season(x,s). 



To constrain the search on the basis of a small budget, we may employ the 
expression: 

Cheap_Holiday = {RN {{Good_P\ace/ Cheap} , Prefs) constrains Holidays) U Prices 

where A constrains DB = (A n DB) U {DB -< A). Namely the predicates 
renamed in Prefs are used to constrain the general rules in Holidays defined by 
means of predicate Good_Place. The obtained expression also keeps all other rules 
from Holidays as well as the rules in Prices. Notice that other choice criteria can 
be expressed by different compositions of the same programs, for instance by 
changing the renaming substitution into {Good_Place/Exclusive}. 



4 Information Hiding 

In the setting described so far, all symbols and predicate definitions of a com- 
ponent are by default visible to other components. There are however situations 
in which we would like to hide (part of) the code of a component to the other 
components. 

Let us first consider a simple form of hiding that can be directly implemented 
by means of the renaming operator. Consider for instance an over-simplified 
database of a journal containing information on papers submitted for publica- 
tion: 

JournaLDB: 

Status (paper, Accepted) <- Accepted (pa per). 

Status (paper, Rejected) <- Rejected(paper). 

Status(paper, UnderReview) <- ^ Status(paper, Accepted), 

^ Status(paper, Rejected), 

Reviewers(paper, refl, ref2), 
Missing_Review(paper, refl, ref2). 

Reviewers(P23-97, Brown, Smith). 



In order to allow external users to query the database on the status of a paper, 
the database manager would reasonably need to hide some of the information 
present in the database, like for instance the names of the referees that are 
reviewing a paper. Intuitively speaking, such a simple form of hiding can be 
implemented by renaming part of the symbols in the database with fresh system 
symbols that cannot occur in any user program. For instance, the name of the 
relation Reviewers can be replaced by a fresh system predicate name, thus making 
Reviewers not visible to other components. 
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A more general form of information hiding is motivated by the abstract data 
type view of components. Consider for instance the programs: 

Palindrome: 

Pal(list) <- Reverse(list,r), list=r. 

Lists: 

Reverse([ ],[ ]). 

Reverse([x|xs],ys) <- Reverse(xs,zs), Append(zs,[x],ys). 

Append([ ],ys,ys). 

Append([x|xs],ys,[x|ws]) <- Append(xs,ys,ws). 

where program Palindrome defines a predicate Pal for determining whether a 
given sequence is palindrome. The definition of predicate Pal makes use of the 
Reverse operation on lists, which is defined in Lists. Following an abstract data 
type view, only the names of the operations on lists should be made visible to 
other modules, while their implementation should be hidden. 

We now show how renaming can be exploited in a disciplined way to im- 
plement various forms of information hiding. Let us first consider an operation 
Export{TTn, E), whose intended meaning is to leave only the names of predicates 
in 7T„ visible to other modules, while hiding to other modules the code of all 
predicates in E. 

Such a form of information hiding can be implemented by means of the 
renaming and union operations. Namely, the expression Export{TTm E) can be 
defined as the union of two expressions: 

(1) the expression E suitably renamed so as to replace each predicate symbol 
p in E with a fresh predicate symbol p' (not visible to the other components), 
and 

(2) a set of bridge clauses of the form p{x) <— p'{x) linking each predicate p 
in 7T„ with the corresponding fresh system predicate p' . 

Syntactically, if tt is the set of predicate symbols occurringjin E and tt' is a set 
of fresh predicate symbols in a one-to-one correspondence with the set tt, then 
Export{nn, E) can be defined as: 

Export^TTn, E) = RN{Tr'/TT,E) U {p{x)^p'{x)\ p G 7 t„ A (p'/p) G tt'/tt}. 

Namely, predicate names in E are renamed with fresh system predicate names, 
which do not occur in any other user progran| so that the entire code of E 
becomes not accessible to other components. Bridge clauses re-introduce a link 
to the names of predicates in 7t„ so that these names become again visible to 
other components. 

® The predicate symbols occurring in an expression E actually are all predicate symbols 
occurring in the program t{E). 

^ The choice of fresh system predicates must be defined in such a way that once a 
symbol has been chosen it will never be chosen again. This can be easily implemented 
by means of a system function able to generate on demand a stream of different 
predicate names. 
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For instance, the operation Export{nn, E) can be used to hide the entire code 
of an expression E while leaving all the names in E visible to other modules. 
For instance, in the previous example, in the expression: 

Palindrome U Fla;port({Reverse, Append}, Lists) 

only the names of predicates in Lists are visible to Palindrome, while the entire 
code of Lists is hidden. The operation Export{nn, E) can be also used to hide 
the code of an expression E while leaving only some of the procedure names in 
E visible to other modules. For instance the expression: 

Palindrome U Export{{Reverse}, Lists) 

combines programs Palindrome and Lists so that the former can only use the 
name of the operation Reverse defined in the latter. On the other hand, the code 
of Reverse is hidden to Palindrome, while Append is fully hidden (both the name 
and the code) to Palindrome. It is worth noting that this usage of renaming 
supports the reconstruction of the form of exportation present in conventional 
modular programming languages, such as Ada and Modula, with a substantial 
difference. Namely, in our framework, by moving renaming at the meta-level, 
each original module can be adapted in several ways to different situations, 
simply by deciding, at the gluing level (viz. at the meta-level), which symbols to 
hide and which ones to keep visible. This allows a higher degree of both flexibility 
and generality. 

In logic-based programming, procedure (viz. predicate) definitions consist 
of sets of clauses which may be distributed over different components, in con- 
trast with the monolithical structure of procedure definitions in conventional 
languages. 

Moreover in logic-based programming the knowledge about a procedure is 
available at two different levels. The intensional definition of a procedure is the 
code of the predicate, i.e. the set of clauses defining it. The extensional definition 
is instead the set of atomic formulae provable for that predicate. Following this 
observation, the use of renaming in a logic program composition setting may 
hence support different forms of information hiding. 

Let us now consider the more general situation in which we wish: (a) to hide 
the code and leave visible the name of some predicates, (b) to leave visible both 
the name and the code of other predicates, and finally (c) to hide both the code 
and the name of the remaining predicates. 

To this end, let us consider a more general definition of the Export operation 
of the form Export'^{'Xn, tTc, E), whose intended meaning is to leave the names 
of predicates in 7 t„ visible while hiding their code, and to leave visible both the 
name and the code of predicates in tTc. All other predicates in E but not in 
(7T„ U 7Tc) are fully hidden. 

Syntactically, if tt is the set of predicate symbols occurring in E and tt' is a set 
of fresh predicate symbols in a one-to-one correspondence with the set (tt — tTc), 
then Export^ {TTn, tTc, E) can be defined as follows: 
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Export'^ {iTn, TTc, E) = RN{tt' / (tT — 7Tc), E) U 

{p{x) ^ p'{x) I p G 7T„ A (p'/p) e n'/in - tTc)}. 

Namely the effect of RN{tt' /{tt — tTc), E) is to make the code and the names of all 
predicates in E except those in tTc not accessible to other components, while the 
bridge clauses re-introduce a link to the names of predicates in 7t„ so that these 
names become again visible to other components. Notice that Export'^ properly 
generalises the definition of Export as Export{'Kn, E) = Export'^{'Kn, {}, E). 

We conclude this section by illustrating another example, whose purpose is to 
further show the benefits of a meta-level renaming operator. Let us reconsider 
the graph example of Sect.^ Imagine again to have two separate data bases con- 
taining information on train connections and flight connections between cities. 
We may then need to find out whether from a given city it is possible to reach a 
destination (i.e., another city) by using either the train only or the plane only. 

A proper combination of renaming and bridge clauses assists us to deal with 
this disjoint union problem. Namely, we can explicitly build the program 

B: 

Path(x,y) <- Train_Path(x,y). 

Path(x,y) <- Plane_Path(x,y). 

and the expression 

B U RN{pi, Graph) U RN{p2, Graph) U Trains U Elights 
where 

Pi = {Train_Path/Path, Train_connection/Arc} and 
P2 = {Plane_Path/Path, Flight_connection/Arc}. 

Alternatively, by relying on the derived Export'^ operator, we may directly take 
into account the expression 

Export'^ {{Path}, Si, RN{pi, Graph) U Trains) U 
Export~^ {{Path}, S2, RN{p2, Graph) U Elights) 

where pi = {Train_connection/Arc}, p2 = {Flight_connection/Arc}, 

Si = {Train_connection} and S2 = {Flight_connection}. 

5 Semantics 

So far we have tried to illustrate some significant possible uses of a renam- 
ing operator for component-based programming, in the context of a family of 
meta-level composition operations over logic programs. The computational in- 
terpretation of program expressions has been defined in Sect. H by means of the 
syntactic transformation r that maps arbitrary program expressions back into 
general programs, which can be then executed by any state-of-art interpreter for 
logic programs. 
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It is however important to define an abstract semantics of program composi- 
tions, besides this transformational semantics, so as to characterise the intended 
meaning of each composition without the need of referring to the correspond- 
ing transformed program. Brogi and Turini showed @ the need of resorting to 
higher-order semantics in order to define compositional semantics for definite 
programs with non-trivial sets of composition operations. The same considera- 
tion applies to compositions of general programs, where in addition the orthog- 
onal aspects of compositionality and non-monotonicity must be reconciled. 

A compositional semantics for general program expressions containing U, n 
and -< operations has been defined in Q in terms of three- valued logic. Although, 
at least at first sight, renaming does not seem to cope with compositionality, it 
is possible to show that the above semantics extends to deal with the renaming 
operator introduced in this paper. 

In order to do this, we first briefiy recall from ^ some definitions and results. 

Fitting Q proposed to use a three- valued logic to formalise the meaning 

of general programs. Three-valued logic models the idea that a query can yield 
three possible outcomes: success, failure, and divergence. Accordingly, a notion 
of three-valued Herbrand interpretation is introduced. Formally, a three-valued 
Herbrand interpretation is a pair I = (/+, I~) of Herbrand interpretations, where 
/+ are atoms assumed to be true, and I~ are atoms assumed to be false. All other 
atoms are assumed to be unknown. Fitting defined a three- valued immediate 
consequence operator <h, which given a general program P and a three- valued 
interpretation I yields a three-valued interpretation. Namely: 

= {T,F) 

where 

T = {A I 3 L \ {A L) G ground{P) and L is true in / } 
and 

F = {A I V T : {A ^ L) G ground{P) implies L is false in I }. 

For example, if a program P consists of the two clauses {a ^ b. c.} and 
/ = (0, {6}), then ^>(P)(/) = ({c}, {a,6}). 

A compositional semantics for program expressions has been defined in Q by 
inductively extending the definition of so that its first argument is an arbitrary 
general program expression. In the following, we will use the notations 
and <P~{E){I) to denote the positive part and the negative part, respectively, of 
the three- valued interpretation 'P{E){I). Moreover, if J is a (two- valued) Her- 
brand interpretation, we will denote by Ext{J) the “extension” of J w.r.t. B, 
that is J extended with all the atoms in B having the same predicate as some 
atom in J. Formally, for each J C B: 

Ext{J) = {p{t) I p{t) £ B A3u : p{u) G J}. 

Then, for any pair Ei, E 2 of program expressions and for any three- valued 
Herbrand interpretation I, we put: 



^EiUE2){I) = {^+{Ei){I)U^+{E 2){I), ^-{Ei){I)n^-{E2){I)) 



The Use of Renaming in Composing General Programs 135 



^{Ei -< E 2 ){I) = {^+{Ei){I) - Ext{K), ^-{Ei){I) U Ext{K)) 
where K = ^+{E 2 ){B,B). 

Namely, the atoms assumed to be true for Ei U E 2 and I are the atoms assumed 
to be true for Ei and I or for E 2 and /. In a dual manner, the atoms assumed to 
be false for the Ei U E 2 and I are the atoms which are assumed to be false for Ei 
and I and for E 2 and 7. The duality of the union and intersection operations is 
reflected by the corresponding definition of the <7 operator. Finally, concerning 
the restriction operation the atoms assumed to be true for Ei ^ E 2 and I 
are all the atoms p{t) assumed to be true for Ei and I except those for which 
predicate p is “defined” in E 2 - Namely, the latter set of atoms can be defined as 
the extension Ext{K) of the set of atoms K which are assumed to be true in E 2 
starting from the whole Herbrand base B. 

Let us now discuss in detail the case of renaming. To this aim, if p = {tt'/tt} 
is a renaming substitution and 7 is a (two-valued) Herbrand interpretation, we 
use the notation: 

I ) = {P(f) I P'(f) & I p' /P G p} U (7 - {pit) I p G 7t}). 

The notation trivially extends to three-valued (Herbrand) interpretations, that 
is, if 7 = (7+,7“) then 7?.(p, 7) = (7?.(p, 7+), 7?.(p, 7“)). The definition of the 
immediate consequence operator <7 can be then extended to deal with renamed 
program expressions as follows. For each expression E, three-valued interpreta- 
tion 7, and applicable renaming substitution p, we put: 

^{RN{p,E)){I) = (J+p , {p{t)\pen} U (J~ - {p'{t) \p' en'})p ) 

where J = ^'(7;)(7^(p, 7)). 

Namely the immediate consequences of a renamed program expression RN{p, E) 
w.r.t. a three-valued interpretation 7 are obtained from the set J of the imme- 
diate consequences of the original expression E w.r.t. the interpretation TZ{p, I). 
The positive consequences simply correspond to the renaming of J'*" via p. The 
negative consequences instead are obtained from the negative consequences J~ 
(suitably Altered of all the renamed atoms) renamed via p and augmented with 
all the atoms whose predicate symbol belongs to tt. 

For example, the program P = {a <- 6, ->c. }, together with the renaming 
substitution p = {a! ja, b' jb} and the interpretation 7 = ({6'}, {c}) give rise to 
the interpretation TZ{p, 7) = ({6}, {c}) and to the consequences: 

<PiRN{p,P))iI) = ((<7+(P)(7^(p,7)))p, {a,6}U(7>”(P)(P(p,7))-{a',6'})p) = 
(<7+(P)({6},{c})p, {a,6}U(<7-(P)({6},{c})-{a',6'})p) = 

({a}p, [a,b}U i{a',b',b,c} - {a',b'})p) = ({o'}, {a, 6,6',c}). 

It was noted that the renaming operator alone is independent from the under- 
lying semantics. This is true in a way, since it is straightforward to define a 
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renaming operator coupled with other well-known semantics for general logic 
programs, like the well-founded or the stable model semantics. However, as we 
will discuss in Sect. Q the advantages of combining renaming with the other 
operators seems to be lost when departing from our chosen semantics. 

It is worth observing that the operations union, intersection, restriction and 
renaming enjoy a number of algebraic properties which are listed in Fig.^ For 
the sake of simplicity, the laws are stated as equalities between program ex- 
pressions, although they represent semantics equalities. Namely E = F means 
<P{E) — ^{F). The constant 1 denotes the program containing a unit clause 
P{x). for each predicate symbol P of the language, while the constant 0 de- 
notes the empty program. The algebraic properties listed in Fig. J provide a 
formal basis for reasoning on (virtual) composition of general program expres- 
sions. For instance, syntactically different program expressions may be formally 
compared and simplified, and equivalent program expressions may be replaced 
one by another for improving efficiency. 



AU 1 = 1 


A ^ A = 0 


AUO = A 


AU B = BU A 


An 1 = A 


AnB = BnA 


Ano = 0 


(A U B) U C = A U (B U C) 


A ^ 1 = 0 


(A n B) n C = A n (B n C) 


A ^ 0 = A 


A U (B n C) = (A U B) n (A U C) 


AU A = A 


An{BijC) = lAnB)u{AnC) 


An A = A 


A ^ (B U C) = (A ^ B) n (A ^ C) 


RN{p,RN(p,A)) = RN{p,A) 


RN{p, A U B) = RN{p, A) U RN{p, B) 



Fig. 1. The algebra of general program expressions. 



Besides the identities shown in the table, there are other interesting relations 
that need some additional conditions to hold. For instance, RN{p, An B) — 
RN{p,A) n RN{p,B) holds provided that p = {tt'/tt} is applicable both to 
A and to B, and furthermore that defs{A) n tt = defs{B) n tt. It is worth 
observing that, when p is injective, the latter condition is not necessary for 
the equivalence to hold. The same conditions are needed in order to satisfy the 
equation RN{p, A~< B) = RN{p, A) -< RN{p, B). 

Finally, it is worth observing that the transformation r introduced in Sect.J 
preserves the three- valued semantics defined by d>. More precisely, each program 
expression E is (^-equivalent to the transformed general program t{E), as stated 
by the following proposition. 

Proposition 1. Let E he a general program expression. Then for any three- 
valued Herbrand interpretation I: 



<P{E){I) = <P{t{E)){I). 
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We have already proved by structural induction Q the validity of Proposition | 
for program expressions not including the renaming operator. We now show how 
the above proposition extends to the case in which general program expressions 
includes the renaming operator. 

In order to do this, we need some preliminary results. 

Lemma 1. Let A be a ground atom, let p be a renaming substitution and let I 
be a two-valued Herbrand interpretation. Then the following relation holds: 

A G 7^(^p, /) y y Ap g I 



Proof. 

Let p = {tt'/tt} and A = q{t). We have to prove the following: 

q{t) G {p{t) I p'{t) Gl A p'/p G p}\J {I- {p{t) \ pGn}) q{t){Tr' /n} G I 

(=J>) Let us reason by cases: 

(z) : q{t) G TZ{p, I) Aq G n {by definition of TZ{p, I) } 

q{t) G {p{t) \ p'{t) G I Ap' /p G p} AqGn q{t){Tr' / tt} G I 
(a) : qft) G Ti-{p, I) Aq ^ TT ^ (by definition of TZ{p, I) } 

qft) G {I — {p{t) I p G 7t}) Aq ^ tt qft) G I A q ^ n =» q{t){n' /n} G I 

(■f=) We must show that: q{t)p G I q{t) G 'R-{p, I). Again, by cases: 

(z) : q{t){Tr' /n} G I A q G tt ^ {let q' / q G p} q'(t) G I A q'/q G p ^ 

{ by definition of TZ{p, I) } q{t) G 72.(p, I) 

(zz) : q{t){TT' /tt} G I A q ^ n =>{ since q{t) is not affected by p } 

q{t) G I Aq ^ TT =^{by definition of TZ{p, I) } q{t) G 72.(p, I) □ 

Observation 1 Let I be a three-valued Herbrand interpretation, B be a con- 
junction of ground literals and p be a renaming substitution. Then: 

(z) B is true in Ti{p, I) <^==> Bp is true in I 
(zz) B is false in TZ{p, I) <;==4» Bp is false in I 

Proof. 

Straightforward, being a direct consequence of the above lemma. □ 



Observation 2 Let E be a program expression and p = {tt'/tt} be a renaming 
substitution applicable to E. Then: 

VA, B \ A-i— B G ground{T{E)) (A ^ B)p G {ground{T{E)))p 
Proof. 

Straightforward. By definition of applicable renaming substitution. □ 
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Now we can address the additional case of Proposition ^dealing with renaming. 
That is, we show that, for each program expression E, and each three-valued 
Herbrand interpretation 7, the following relation holds 

HRN{p, E)){I) = <P{t{RN{p, E))){I) 

The case of renaming is handled by analysing, for the positive and negative part 
respectively, three different (sub-) cases. In fact, each symbol belong to exactly 
one of the three disjoint sets tt, tt' and the complement of (tt U 7t')B Each case 
is based on a series of equivalence steps. The steps for the positive cases are 
sketched below. 

Proof. 

Case (i): <P+{RN{p, E)){I) 

(1.1) : name{A) G tt. 

By definition of 'P'^{RN{p, E)) and of renaming p, we have that V7 j!A : A G 
{<P^{E){7i{p, I)))p A name{A) G TT. On the other side, since the program 
t{RN{p, E)) = t{E)p does not contain any definition for symbols occurring 
in 7T it turns out that V7 ^A: A G {<P'^{t{RN{p, E)))){I). 

(1.2) : name{A) G tt'. 

The relation A G <P~^{RN{p, E)){I) holds, by definition of <P^{RN{p, E)) and of 
renaming p, if and only if 3 A' : A — A'pAname(A') G ttAA' G <P'^{E){Tl{p, /)). 
By inductive hypothesis on E and by definition of we get that 3A',B : 
A = A'p A A' ^ B G ground(T(E)) A B is true in TZ{p,I). ^From Ob- 
servationjwe have 3A',B : A = A'p A (A' r- B)p G {ground{T{E)))p A 
B is true in TZ{p,I). Now, from LemmaJ we obtain 3A',B : A — A'p A 
A <— Bp G {ground{T{E)))p A Bp is true in L Since for each program P 
and each renaming p, the relation {ground{P))p = ground(Pp) holds, then 
3A', B : A = A'p A A <— Bp G ground{T{E)p) A Bp is true in 7. By definition 
of this equals A G <P+(r(75)p)(7). By definition of t(RN{p,E)) we finally 
achieve A G <P+(t(RN(p, E)))(I). 

(1.3) : name{A) ^ (ttUtt'). 

The relation A G <P+(7?7V(p, 7f))(7), by definition of <P~^{RN{p, E)), equals to 
A — Ap A A G <P+(7f)(7?.(p, 7)). Now, by inductive hypothesis, we have A = 
Ap A A G <?+(r(7f))(7?.(p, 7)). This, by definition of holds if and only if 
3B : A <— 73 G ground{T{E)) A B is true in TZ{p, 7). This, by Lemma| means 
that 373 : A <— 73 G ground{r{E)) A Bp is true in I A A = Ap. Since for each 
program P and each renaming p, the relation {ground{P))p = ground(Pp) 
holds, then 373 : (A ^ 73)p G ground{{T{E))p) A Bp is true in I AA = Ap. By 
definition of this equals A G <P'^{t{E)p){I), from which we finally obtain, 
by definition of r, the relation A G {t{RN {p, E))){I). 

Case (ii): A G ^~{RN{p, E)){I) 

The proof is analogous to Case {i), and hence omitted. □ 

® Each proof step may implicitly use the set membership hypothesis specified at the 
beginning of the proof case. 
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By virtue of the above equivalence result, the three- valued semantics of general 
program expressions can be then related Q to various operational semantics for 
general programs proposed in the literature. 



6 Concluding Remarks 

The concept of renaming has been widely studied and employed in mathematics 
and computer science for different purposes, including program composition. For 
instance, adopting an algebraic approach for defining the semantics of module 
and module compositions, Bergstra et al. ^ introduced a renaming operator for 
combining different signatures. However, the kind of renaming they proposed is 
“permutative” , that is, if a is replaced by b, then b is replaced by a. This can 
be useful for avoiding name clashes, but not for purposes such as increasing or 
decreasing the cooperation between different parts of code, as we intend to use 
it. Indeed, our renaming operation is idempotent rather than permutative, and 
it is not even injective in the general case. This allows a description of several 
kinds of code integration. In reality, our renaming operator is more similar to 
the concept of signature morphism In this respect, the notion expressed by 
our function TZ{p, I) can be viewed as an adaptation of the forgetful function to 
our context. 

It is worth outlining that a renaming facility can be easily defined to cope 
with other semantics for general programs, such as the stable model semantics 
19, or the well-founded semantics 99- This is not surprising, since renaming 
by itself is just a vocabulary change. Nonetheless, we argue that renaming can 
become really useful when used in combination with other operators, like the 
ones we presented in this paper. For instance, given the programs 

G: F: 

Direct_Conn(x,y) <- Arc(x,y). Flight(Pisa, Paris). 

Undirect_Conn(x,y) < — i Arc(x,y), Flight(Paris, London). 

Path(x,y). 

Path(Pisa, London). 

Path(Pisa, Paris). 

and building the expression E = GU i?iV({Arc/Flight}, F) we obtain, through 
the calculus of the powers of (P{E) starting from the empty interpretation (0, 0), 
the positive conclusions Direct_Conn(Pisa, Paris), Direct_Conn(Paris, London) and 
Undirect_Conn(Pisa, London). 

A similar result could not be obtained by combining the renamed models of 
the two programs. Indeed, evaluating separately the powers of for the programs 
G and F and then renaming predicate Flight into Arc leads to derive unwanted 
conclusions, such as Undirect_Conn(Pisa, Paris) and not to obtain some of the 
desired information (e.g., Direct_Conn(Pisa, Paris)). 

The same problem occurs also with other well-known semantics, such as the 
well-founded semantics ^9, the stable models semantics or perfect models 
semantics ^9- 
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In our case, we succeed because our compositionality results for three- valued 
semantics have been established in terms of the three-valued immediate conse- 
quence operator associated with programs rather than in terms of the models of 
programs. In this respect, the other cited semantics for general programs seem 
to lack an easy compositional, second order characterisation. 

The need for resorting to second order semantics for defining compositional 
semantics of logic programs was already pointed out in the case of definite pro- 
grams. Brogi and Turini showed that the equivalence relation induced by the 
immediate consequence operator T is the fully abstract compositional equiva- 
lence relation for an algebra of logic programs containing several composition 
operations over definite programs. In this perspective the compositionality of 
other models could be studied in terms of second order functions used for com- 
puting such models. For instance, one could consider the fixpoint operator used 
for computing the well-founded models of a program. However, differently from 
the case of Fitting’s operator, it seems that in the case of well-founded seman- 
tics there is no simple composition on fixpoint operators which is homomorphic 
to the operation of union on programs. 

Several other efforts have been devoted to investigate the composition of gen- 
eral logic programs. Some compositionality results for extended logic programs, 
including general programs, were established by Brogi et al. in The authors 
showed that many semantics for general programs (such as stable models, well- 
founded models, stationary expansions f ^-J , complete scenaria |3]) can be defined 
in terms of the Herbrand models of the positive version of a program. The com- 
positionality of Herbrand models w.r.t. the union of programs then induces gen- 
eral compositionality results for the various semantics considered. While these 
results can be applied to different semantic frameworks, only the operation of 
union between programs is considered. Unfortunately, as shown for instance in 
Q, the Herbrand model semantics is not compositional for other operations, like 
the intersection or restriction operations considered in this paper. 

Lifschitz and Turner investigated the idea of splitting a logic program 
into parts in the context of the answer set semantics The basic idea is that, 
in many cases, a program can be divided into a “bottom” part and a “top” 
part, such that the latter does not refer to predicates defined in the former. 
Lifschitz and Turner showed that computing the answer sets for a program can 
be simplified when the program is split into parts. They also showed that the idea 
of splitting can be applied for proving properties of simple program compositions, 
like a conservative extension property for a program P extended by rules whose 
heads do not occur in P. 

Etalle and Teusink | and Verbaeten et al. studied the problems of 
defining compositional semantics for general logic programs. Etalle and Teusink 
B define a compositional semantics for general programs by means of a first- 
order unfolding operator. Such a semantics is applied for composing “open” 
general programs by considering the union of programs as the only composition 
operation. 
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Verbaeten et al. in present several results on the compositionality of 
general logic programs by generalising the well-founded semantics of logic pro- 
gramming. More precisely, they identify some conditions under which the class 
of extended well-founded models of the union of two general programs coincides 
with the intersection of the classes of extended well-founded models of the two 
programs. 

All these approaches differ from ours since the union of programs is the 
only composition operation considered, and since a restrictive naming policy is 
imposed on the predicate names of the programs to be composed. Namely, in 
contrast with our naming policy, predicate definitions cannot be spread over 
different programs. 

Recently, Verbaeten and Bossi provide an attempt to compose separate 
programs sharing predicate definitions, according to the generalisation of the 
well-founded semantics already presented in it is argued in Q, this 

will reflect the quite common situation in which two programs both have an 
incomplete knowledge over the same predicate. The authors discuss some condi- 
tions required in order to enforce the compositionality of the chosen semantics 
characterisation, when dealing with such situations. 

The use of parameterisation proposed by Hill for typed logic-based lan- 
guages shares some of the objectives of our work. Hill considered two kinds of 
parameters: “open” parameters to support code linking, and “renaming” param- 
eters to support code reuse. 

As we have shown, both these mechanisms can be expressed in our setting, 
and the main differences between our work vs. ^3 are to consider a family of 
composition operations vs. only one module composition operation, and the use 
of untyped vs. typed programs. 

^From an implementation viewpoint, the transformation r for the renam- 
ing operation has been developed in SICStus Prolog. This actually enriches, 
in a practical applicability perspective, the toolkit for composing general logic 
programs described in Q. 

Future work will be devoted, on the one side, to tackle real-size problems 
and applications exploiting the proposed framework. On the other side, also 
other semantics for general programs with respect to compositionality as well as 
different kind of programs and program compositions are worth investigating. 
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Abstract. Based on a variable-free combinatory form of definite clause 
logic programs we outline a methodology and supporting program en- 
vironment CombInduce for inducing well-moded logic programs from 
examples. The combinators comprise fold combinators for recursion on 
lists. The combinator form is distinguished by enabling piecewise com- 
position of semantically meaningful program elements according to the 
compositional semantics principle. The principle of combining programs 
from combinators admits induction of programs without appealing to 
most-specific-generalization and predicate invention in contrast to pre- 
vailing ILP approaches. Moreover, the combinator form avoids confusing 
object and metavariables in the applied metalogic program environment. 
In addition useful algebraic rewriting rules can be formulated conve- 
niently with the combinators. 

Keywords: logic program schemata, logical combinators, synthesis by 
composition and specialization of schemas, inductive synthesis, metalogic 
program environment. 



1 Introduction 

Induction of logic programs (ILP) is traditionally conducted as a generalization 
process in which program clauses are synthesized based on a number of program 
input /output examples. In the logic programming context it is natural to appeal 
to anti-unification of terms and atomic formulae, see e.g. This prevailing 
approach conforms with induction of logical rules from mass data as carried out 
in the machine learning tradition. 

The present approach to ILP focuses on pure logic programs for list process- 
ing, which call for recursive formulations except for the most trivial cases. How- 
ever, in the above mentioned bottom-up oriented approaches it has turned out to 
be difficult to synthesize recursive program structures (i.e., programs applying 
recursively defined predicates) from sample facts with no a priori indication of 
recursive structure. In MetaInduce in ^ we tried to tackle this problem by 
suggesting that the program structure to be induced has to comply with given 
recursion schemes of universal nature. The induction process then essentially re- 
duces to synthesizing of auxiliary predicates applied as parameters or arguments 
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to the recursion schemes. The auxiliary predicates in simpler cases would be de- 
fined by non-recursive clauses formed by a least general generalization procedure 
from the examples. In more complex cases the whole induction procedure may 
be invoked recursively to invent a new recursively defined auxiliary predicate. 

The approach to be introduced here, CombInduce, also draws on recursion 
schemes but differs from MetaInduce by applying a novel combinatory form of 
logic programs COMBILOG introduced in Q enabling variable-free formulations 
of definite clauses. The use of combinatory logic enables us to discard of least 
general generalization as well as predicate invention. Thus a key issue in the 
paper is the usefulness of the combinatory form of programs for ILP in which 
recursion schemes are added as “super” -combinators. 

A key feature in our inductive synthesis is insistence on well-moded programs 
as a constraint which drastically reduces the search space. 

Among the various ILP methods discussed in Dialogs 0 is 

probably the system coming closest to our proposal. However, as mentioned 
CombInduce does not apply least general generalization and predicate inven- 
tion. 

The paper is outlined as follows: Sect. 2 introduces to the combinator form 
of clauses applied in Combilog. Sect. 3 extends Combilog with recursion com- 
binators for list processing. Sect. 4 outlines a methodology and environment for 
inductive synthesis of logic program using the combinatory form. Finally sect. 
5 discusses examples of program induction and outlines the synthesizer as a 
metalogic program. 

2 Compositional Logic Programming 

In the structured programming tradition programs are composed from specifica- 
tions in a top-down problem decomposition manner, according to which a larger 
program is obtained by putting together smaller programs by means of com- 
bining forms. In functional programming functional composition offers itself as 
one of the forms together with conditionals and certain recursion forms, cf. e.g. 
QQ. In logic programming it is more difficult to identify combinators since — in 
contrast to binary predicates — there are no standard combining forms for n-ary 
predicates. 

In functional programming a combining form such as, say, functional compo- 
sition is naturally understood as a higher order function taking functions as argu- 
ments and yielding a function as result. Similarly, in the context of logic and logic 
programming new predicates (model-theoretically conceived of as truth-valued 
functions) are to be formed by composition of basic predicates or program defined 
predicates by means of combining forms functioning as higher-order predicates. 

2.1 Combinators for Logic Programs 

In a recent paper Q we pursue the compositional principle in the context of logic 
programming by proposing a variable-free combinator form of definite clauses 
termed COMBiLOG. We consider here only pure definite clauses 
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• • • ; ^Ono) • • • : ^Ini) A ... A • • • 5 

devoid of extra-logical and non-monotonic features. Assume that a collection of 
defining definite clauses for a predicate p be of the form 

7 0i 

p{x) ^ \J /\q^J{tij) 
i j 

where X are tuples of distinct variables and tij are tuple terms conforming with 
the arity of the predicates. The elimination of left hand side non-variable terms 
proceeds by appealing to a distinguished clause id{X, X) through rewritings (cf. 
e.g. Q) which do not affect the declarative semantics. Without essential loss of 
generality it is assumed that compound terms are list terms, and moreover that 
goal clauses are of the form ^ p{X). 

In COMBILOG this is replaced by combinatorial defining clauses 

p^ (fi 

where is a ground combinatory predicate term of the form 

(cterm) ::= (pid) \ {comb){{cterm){, (cterm)}*) 

where (pid) is a predicate identifier and {comb) is one of the three combinators 
and, or, and make[pi, . . ., /im], where pi are index numbers. These three combi- 
nators are identified as the least semantically meaningful building blocks being 
sufficient and necessary in our reconstruction of clauses. The combinators can 
be defined as follows in the informal use of higher order predicates. 

or(P,Q)(Ai,...,A„) 

or{P, Q)(Ai, . . . , A„) ^ Q(Ai, . . . , A„) 

and{P, Q)(Ai, . . . , A„) ^ P(Ai, . . . , A„) A Q{X ^, . . . , A„) 

make [p\ , . . . , /r„](P)(A^„ . . . , ^ P(Ai, . . . , A„) 

Here P and Q are predicate arguments and the combinators may be conceived of 
as higher order predicates used similarly to higher order functions in functional 
programming. These combinators are of generic arity and in addition make is 
indexed with m distinct positive index numbers. It should be observed that 
the above clauses serve explanatory purposes; they do not belong to the object 
language. 

As an example the combinator inverse for binary predicates comes about 
as the definition of combinator make\2, 1 ], that is, as an instance of the above 
generic definition 

mafe[2,l](P)(A2, Ai) ^ P(Ai, A 2 ) 

These combinators are inspired by a proposal by Quine ^3 for a variable- free 
form of full first order predicate logic, see Q for a comparison and discussion. 
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It should be observed that Combilog is not intended as a fully-fledged 
higher order logic programming language. Although the combinators function 
as higher-order functions, they serve to form program denotations, and they are 
not available as data in contrast, say, to A-Prolog. 

The predicate identifiers include, besides user introduced predicate names, 
the primitive predicates id, cons, constc, true, false definable by the following 
unit clauses (no clauses for false) 

id{X, X) 
cons{U,V,[U\V\) 

constc{c) for all relevant constants c, including [] 
true 

As an example the clause head{[X\_], X), i.e., 
head{L, X) <— eons{X,T, L) 
in Combilog is defined by 

head <— make[3, l](cons) 

As it appears, in COMBiLOG all manipulations of non-variable terms are 
relegated to the primitive predicates cons (is 3-ary) and constc (is 1-ary). 

Sect. 3 and following sections provide more complex program examples. 



2.2 Semantics for Combinators 

In Q is proven combinatory completeness (relative to the defining definite clauses 
above) of these combinators in a canonical form with the defining term 

or] {make[fii]{and^' {make [fiij ] qij )) ) 



where 



or]{4>i) = 4>i or 4>2 or . . . or 4>n 



and 

and]{(pi) = (pi and p 2 emd . . . and </>„. 

The defining term reflects the defining formula \/] /\^‘ qijiUj). 

The combinatory form of clauses invites formulation of a compositional se- 
mantics so that the relational denotation of the term comb{ipi, . . . , (fn) is de- 
termined as a function Fcomb of the relational denotations of the subterms 



lcomb{(pi, ..., (/?„)] = Fcomf,(|(/3i], . . . , {(Pnl) 



The semantical definitions of the combinators are as follows 
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|anrf((/3, V-)! =MnM 

|or((/3, ■0)1 = U 10] 

lmake[iii,...,n^]{(p)j = . . . 0^^) G 17™ |3(7i, . . . , 7„) G M} 

or more explicitly for make 

|mafce[Aii,...,/r„]((/3)l = {{t[, . . . ,t'^) G iL™ |3(7i, . . . , 7„) G M 

s.t. for i = l..m if /ii < n then t' = tf^^} 

where H is the Herbrand universe of the program. Thus make[l, 2, . . .,n] is the 
identity combinator for n-ary relations, i.e., 



|maA:e[l,...,n](P)] = |P] 

and the term make[l, 2, . . n]{true) yields the n-ary universal relation P" from 
the 0-ary true, i.e., 



|maA:e[l, 2, . . . , n]{true)} = P". 

The denotations of the primitive predicates are as follows 



lidj 


= {{t,t) G p2|t G P} 


Icons] 


= {(7',7", [tn&H^ 1 0,7"gP} 


{const d 


= {(c)} for all relevant constants c 


{true} 


= {()} 


Ifalsej 


= {} 



These definitions are proved in Q to make the semantics coincide with the 
usual least model and fix point semantics of corresponding definite clauses for a 
COMBILOG program. 

Thus, in the construction of the least fixed point for a combinatory form 
of program the iteration step reduces to set union, intersection and generalized 
projection. 



3 Recursion Combinators 

In the combinator language COMBiLOG as summarised above recursion is han- 
dled like in ordinary logic programs by introduction of predicates defined in 
terms of themselves directly or indirectly. One way of eliminating these recur- 
sive definitions would be to introduce a general fix point combinator (cf. the Y 
combinator in combinatory logic). However, we prefer to introduce list-oriented 
recursion operators analogously to functional programming practice BO- 
PB we propose two fold combinators for list recursion defined, e.g., as follows. 

foldr{P,Q){Y,[],Z)^Q{Y,Z) 

foldr{P, Q){Y, [X\T],W) ^ foldr{P, Q){Y, T, Z) A P{X, Z, IT) 
foldl{P,Q){Y,[],Z)^Q{Y,Z) 

foldl{P, Q){Y, [X\T],W) ^ P{X, Y, Z) A foldl{P, Q){Z, T, W) 
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which are relational counterparts of the well known functional operators 
Similar to the logic combinators we have for the recursion combinator foldr (and 
the logically equivalent operator foldrrev, see below) the semantical definition: 

lfoldr{P,Q)j =\JT=olfoldniP^Q)l 
Ifoldr^iP, Q)1 = {{y, [], ^) € z) € |Q]} 

|/oWr,+i(P, Q)1 = {(y, [ti\t 2 \,w) e Idz e H s.t. 

{y, t 2 ,z) G lfoldr^{P, Q)1 A (ti, 2 , w) G |P] } 

Similar recursion operators are proposed in Q applying A-Prolog, whereas 
our combinators are made available in ordinary logic programming as explained 
in the next section. 

For instance the relational append predicate definition in the formulation 
append X) 

append\[X\T], Y, Z) <— append(T^ Y, U) A cons{X^ [/, Z) 
in the /oW-extended COMBILOG becomes 

append - make[2, 1, 3](/oWr(cous, id)) 

where make[2, 1, 3] swaps the two first arguments {since foldr differs from append 
in that the second argument, not the first, is the induction parameter). The use 
of append with only third argument being ground calls for a replacement with 
a logically equivalent variant of foldr. 

foldrrev{P,Q){Y,[],Z)^Q{Y,Z) 

foldrrev{P, Q){Y, [X\T],W) ^ P{X, Z, W) A foldrrev{P, Q){Y, T, Z) 

The short and elegant combinatory formulation of append is seductive since 
combinatory formulations are admittedly sometimes awkward. For instance the 
unit clause 

make -unit Jist{X, [Xj)]]) 
via the reformulation 

make -unit -list{X,Y) ^ const ]^{Z), cons {X, Z,Y) 
which serves to remove non- variable terms, yields the combinatory definition 
make -unit -list <— make[l,3]{and{make[2, 1, 3](const[|), cons)) 

being in the canonical form mentioned in sect. 2.2. 

In B we prove that logic program recursion with the fold schemes suffices for 
expressing all partial and general recursive functions. However, this is a purely 
theoretical result; in logic programming practice non-linear recursion forms such 
as and- or problem reduction schemes are convenient, cf. Still the empirical 
investigation in | tells that most common pure logic programs can be naturally 
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formulated within the fold schemes; therefore we confine ourselves to the fold 
schemes in the present context. 

Actually in [j] we state and in Q] we prove duality theorems which in the 
present combinator form looks like 

lfoldr{P, Q)] = |maA:e[3, 2, l](foldl{make[l, 3, 2](P), make[2, 1](Q)))] 

lfoldl{P, Q)] = |maA:e[3, 2, l]{foldr{make[l, 3, 2](P), make[2, 1](Q)))] 

connecting the two fold operators in the declarative, that is model theoretic or 
fix point, understanding of logic programs. 

For logic program expressible with the fold combinators, in the combina- 
tor formulation of such programs it is unnecessary to introduce user specific 
predicate names since a program may take form of ground combinator term 
comprising only the primitive predicates. 



4 Synthesizing Combinatory Logic Programs 

In this section we sketch a methodology and programming environment for con- 
ducting inductive synthesis of logic programs in the pure combinator form 

{cterm) ::= {comb){ [ {cterm) { , {cterm) }* ] ) 

where primitive predicates are conceived of as 0-ary primitive combinators and 
(comb) includes, besides and, or and the indexed make, the operators foldl(rev) 
and foldr(rev). 

The program synthesis environment is established as a metalogic program in 
which the combinator terms appear as ordinary terms using a technique orig- 
inating in ' ” i , pursued in * - | . This is exemplified with the generic predicate 
apply, which expresses application of a predicate term to its arguments, hence 
serving as an abstract machine for logic programs. For and and make there are 
the clauses: 

apply {and {P,Q), [AJ) ^ apply{P, [Ai]) A apply{Q, [Ai]) 
apply{and{P, Q), [Xi, A 2 ]) ^ apply{P, [Xi, X 2 ]) A apply{Q, [Xi, X 2 ]) 



apply{and{P, Q), [Xi, ..., A„]) ^ 

apply{P, [Xi, ..., A„]) A apply{Q, [Xi, ..., A„]) 
apply {make {[fii, . ..,p,^],P), [A^,, . . ., A^„]) ^ apply{P, [Ai, . . ., A„]) 

up to some fixed maximum arity m and n. 

For foldr there is the clause 

apply {foldr{P, Q), [Y, [], ^]) ^ apply {Q, [Y, Z]) 
apply{foldr{P,Q),[Y,[X\T],W]) ^ 
apply{foldr{P, Q), [Y, T, Z]) A apply{P, [A, Z, IT]) 
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Similarly for primitive predicates id, cons, const c and true 
apply{id, [X, X]) 
apply{cons, [X, T, [XIT]]) 
apply {const c, [c]) for each relevant constants c 
apply {true, []) 

For instance, for combinator make[ 3 , 1 ] we have 

apply{make{[ 3 , 1 ],P), [X3, Xi]) <- apply{P, [Xi, X2, X3]) 

The apply predicates enable execution of combinatory programs in the meta- 
logic programming environment established with ordinary clauses. Thus the 
query ^ p with p defined by p <— (/? is stated as 

^ apply{y^: [Xi, . ..,Xm]) 

Consider, for example, the derivation 

^ apply {make{[i^, 1], cons), [Jfi, JA2]) 

^ apply {cons, [X2, _, Xi\) 

The resulting semantics is proved equivalent in Q to the semantics defined 
in sect. 2.2. for the combinators. 

During the course of the induction the combinator terms being synthesized 
may be non-ground, with the variables representing unknown (sub)combinator 
terms. Thus our induction procedure proceeds by specializing (instantiating) 
partially specified combinatory program forms guided by a given program result 
test suite. 

An advantage of the combinatory program form in the synthesis processes 
is that the absence of the object program variables eliminates confusion with 
the metavariables whose range are combinatory terms, i.e., subprograms. More 
importantly, the fact that the strict compositional semantics is refiected directly 
in the syntax ensures that subprograms represented by combinators can be syn- 
thesized independently of the embedding program context. This is in contrast to 
ordinary logic programs where a clause has to be completed before it represents 
a semantically meaningful entity. 

The combinator term to be synthesized fulfills the following grammar 

{cterm) ::= make[ii , . . . , in]{{primpred)) \ 

make[ii, . . ., in]{foldr {{cterm) , {cterm))) \ 
make[ii , . . . , in]{foldrrev{{cterm), {cterm))) \ 
make[ii, . . ., in]{and {{cterm) , {cterm))) 

{primpred) ::= id \ cons \ const \ true \ false 
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corresponding to the above canonical form enriched with the foldr combinator. 
The identity combinator mafce[l, 2, . . n] is left implicit in terms. 

The or operator is omitted since we have the following equivalences 

I/oWr(or(Pi, P 2 ), Q)1 = \or{foldr{P^, Q),foldr{P 2 , Q))l 

lfoldr{P, or(Qi, Q 2 ))l = [or(/oWr(P, Qi)Joldr{P, ^ 2 ))! 

which entails that a program requiring the or combinator can be a priori decom- 
posed into or- free programs since or can distributed over foldr in both arguments 
and hence can be propagated to the top. 

We insist on synthesized programs being well-moded, cf. | for reasons clar- 
ified in the next section. This means that program predicates are assigned 
mode specifications telling the input arguments (-I-) and output arguments (— ). 
The well-modedness constraint implies that if the input arguments are ground, 
ground terms will be produced in the output arguments. 

As an initial simple example for illustrating the induction principle is con- 
sidered the synthesis of the head predicate /iead([A|_], A) from sect. 2.1. 

Assume given the test suite [ [[a, b],a], [[&], b] ] together with the mode spec- 
ification [+,—]. Following the above grammar for the combinator program we 
consider first as candidate a program consisting simply of a primitive predicate. 
The only primitive predicate which conforms with the arity is id which fails on 
the test samples. 

As a next step is considered a combinator program of the form make [i \ , * 2 ] (P) 
where P is primitive and fi,i 2 € {1..3}, 3 being the maximum arity of the 
primitives. 

The choice P = false is ruled out because the denotation of the program is 
then the empty set which does not cover the examples. The choice P = true 
yielding a universal relation is ruled out since the corresponding program does 
not conform with the mode requirement. 

Finally is considered P — cons, which yields a correctly moded program with 
make[S, 1] and make[S, 2]. However only the program make[S, l](cons) covers the 
test examples, and is therefore considered the result of the inductive synthesis 
as the smallest well-moded program covering all test examples. 

5 Outline of the CombInduce Synthesizer 

Having above described the principles for our inductive synthesis approach we 
now turn to a more systematic account of our synthesis method. The aim of the 
synthesis process is to provide a syntactically smallest n-ary predicate term (f 
which covers the suite of test example n-tuples ti,t 2 , ■ ■ ■, tg, i.e. 

S 

C |(^] C |maA:e[l,2, . ..,n]{true)j = Ff” 

i=l 

As indicated mode constraints are critical to our induction approach since 
abandoning of the constraints would admit the universal relation as simplest 
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solution in absence of negative examples. Let us introduce the notion of valence 
for the combined constraints of modes, types and arity, assuming synthesis of 
well-moded programs Q only Q. The intuition is that composition of combina- 
tors are subject to constraints like valence constraints on chemical atoms and 
radicals. For simplicity’s sake data type constraints are not taken into account 
in the below formulation. 

In principle the synthesis can be carried out as a search for the smallest pred- 
icate term tf fulfilling the above set inclusion. The imposed valence constraints 
prunes the search tree in the top-down construction of the program term when- 
ever the valence constraint turns out to be violated. It is our contention that the 
valence constraints drastically reduce the search space as already indicated by 
the above small example. 



5.1 The CombInduce Synthesizer as a Metalogic Program 

The heart of the synthesizer are defining clauses for a mutually recursive pred- 
icates syn and synjmake drawing on the above defining clauses for the combi- 
nators. This program structure is to ensure that combinators obey the above 
grammar. We suggest that the search is bounded by the size of the term being 
synthesized measured in terms of the number of identifiers, similarly to the it- 
erative depth first strategy. Thus termination is not ensured. The bound is set 
successively at 1,2,.... For simplicity’s sake the search control is abstracted in 
the below program outline. 

The top level is 

synthesize Valencel, Exl) <— syn_make{<P, Valencel, Exl) 

Synthesis of the above example head_ofJist is initiated with a goal clause 
^ synthesized^, [[+,-]], [ [[a, &],a], [[b],b] ]) 
where the synthesized predicate term obtains as binding to 

syn_make{make{Il, P), Valencel, Exl) <— 

makejvalence{Il, Valencel, ValencelV), 
make -example {II , Exl, Exll), 
syn{P, Valencell, Exll) 

The auxiliary predicates makc-valence and make-example carry out neces- 
sary permutations as specified by the index list II. 

For the primitives there are 

syn{id, Valencel, Exlist) <— 

check-valence{Valencel, [+,—]]), 

test -examples {id. Exlist) 

syn{cons, Valencel, Exlist) <— 

check -valence{ Valencel, [[-|-, -I-, — ], , — , -|-]]), 

test -examples {cons. Exlist) 
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syn(constc, Valencel, Exlist) <— 

check -valence{ Valencel, [— ]), test-examples {const c. Exlist) 
syn{true, [],-) 
syn{false, [], []) 

test -examples {Pid , []) 

test -examples {Pid , [Ex\Exl]) <— apply{Pid, Ex), test -examples {Pid, Exl) 
Recall that apply is defined in sect. 4. 

The mode notation is rather self-explanatory; for instance the modes for 
id require that either the second or first argument (or both) be ground upon 
invocation of id. 

More clauses for the predicate syn corresponding to the fold and and com- 
binators are added in the below subsections. 



5.2 Synthesis with the Fold Combinators 

In order to bring foldr combinators into play the following clauses are added 

syn{foldr{P,Q), Valencel , Exl) ^ 

valence {foldr, Valencel, Valencell, Valencel2), 
make-examples -foldr{Exl , Exll, Exl2), 
syn-make{Q, Valencell , Exll) , 
syn-make{P, Valencel2, Exl2) 

syn{foldrrev{P,Q), Valencel, Exl) ^ 

valence{foldrrev, Valencel, Valencell, Valencel2), 
make -examples -foldrrev {Exl , Exll, Exl2), 
syn-make{Q, Valencell , Exll) , 
syn-make{P, Valencel2, Exl2) 

The predicate valence establishes relationship between the valences of the 
combinator term foldr{P, Q) and valences of its predicate arguments P and Q 
according to the following mode specifications from Q. 

foldr {[+, -h, — ], [-I-, -])[-!-, -h, — ] 
foldr{[+, -h, — ], , —])[—, -h, — ] 
foldrrev{[+,-,+], [-,+])[-,+,+] 
foldrrev{[+,-,-], 
foldrrev{[-,-,+], [-,+])[-,-,+] 

The first line tells that if foldr{P, Q) is to be used with the mode [-I-, -I-, — ] 
then the mode requirement for P is [-I-, -I-, — ] and for Q is [-I-, — ], etc. 

As an example consider the inductive synthesis of append, say, from the test 
suite Exl 



154 Andreas Hamfelt and J0rgen Fischer Nilsson 



and with valence specification Valencel equal to the list [ [+,+,—] ]• When the 
search process comes across the term 

make[2, 1, 3]{foldr{P, Q)) 

according to the above mode specification for the unknown subterm Q is obtained 
from the example [[], [], []] by use of foldr the test suite [ [[], []] ] with valence list 
[ [+, — ] ] yielding Q = id as simplest solution. For the unknown subterm P by use 
of foldr on the remainder examples [ [[o], [], [a]], [[a, 6], [c], [o,6,c]] ] is obtained 
the test suite [ [a, [], [a]], [b, [c], U], [a, U, [a, b, c]] ] with valence list [ [+, +, — ] ] 
solved by P = cons . The logical variable U linking the test examples stems from 
the recursive unfolding of foldr carried out in makc-examples-foldr. 

Actually the curtailed test suite 



would suffice for synthesizing the same solution for append. 

The same test suite with the valence specification in the induction 

process calls for use of foldrrev instead of foldr giving 

make[2, 1, 3]{foldrrev{P, Q)) 

According to the above mode spefication for the unknown subterm Q is ob- 
tained the test suite [ [[] , []] ] with valence list [[-,-!-]] yielding Q = id, and for the 
unknown subterm P is obtained the test suite [ [a, [], [a]], [a, U, [a, b, c]], [b, [c], U] ] 
with valence list [ ] solved by P = cons. 

This example illustrates selection of the proper foldr variant in order to 
obtain a correctly-moded program constituting an integral part of our inductive 
synthesis method. 

Extension with the foldl variants is straightforward. 



5.3 Synthesis Involving the And Combinator 

The and combinator is the most complex component in the present approach, in 
part due to the mode patterns, in part due to the possibility of increasing the ar- 
ity of predicates reflecting use of right hand side variables only in clauses. In order 
to illustrate these problems we consider the example from above make -unit Jist 

make -unit -list {X, [A|[]]) 

becoming in COMBILOG: 

make -Unit -list ^ make[l,3]{and{make[2, 1, 3](const[]), cons)) 

We consider induction of make -unit -list from the two examples [a, [a]] and 
[[a, b], [[a, &]]] with the mode specifications [-I-, — ] and , -I-]. All of the valence 
constraints have to be satisfied by a synthesized program. 
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In bottom up oriented approaches to ILP synthesis of this program is trivially 
achieved as the least general generalization of the examples. By contrast syn- 
thesis of this program in this present approach is more intricate since as already 
noticed it calls for the compound combinator form 

make [/r] (and {make [/ii] ((/?i ) , make [^ 2 ] {‘P 2 ))) 

This is achieved by the following clause in which the list variable II, III and 112 
represent, respectively, the index lists /i, and /i 2 - 

synjmake{make{Il, and{make{Ill, PI), make{Il2, P2)), Valencel, Exl) ^ 
valence{Valencel, Valencell, Valencel2, II, III, 112), 
make -example {II, III, 112, Exl, Exll), 
syn{Pl, Valencell, Exll), 
syn{P2, Valencel2, Exll) 

The auxiliary predicate valence is to assign valences to subterms PI and P2 
observing well-modedness constraints in jointly choosing /r, ni and /i 2 - 
In the present example we synthesize 

make[l, 3]{and{make[2, 1, 3](P1), make[l, 2, 3](P2))) 

which is reducible to 



make[l, 3](and(maA:e[2, 1, 3](P1), P2)) 
in which the and combinator is ternary conforming with the clause 

{X,Y)^P1{Z),P2{X, Z,Y) 

With these choices of p,, pi and p 2 , PI has the mode specification [— ] but 
no examples provided. The first choice for PI then is constant const Ac- 
tually if type constraint be taken into account the type has to be a list so 
const ^ is the only const combinator available. For P2 the specificed modes are 
[ [—,+,+] ] and the examples with the chosen values for P2 are 

[[a, &],[], [[a, &]]] and [a, [], [a]], giving P2 = cons, thus 

{X, Y) <— const^{Z), cons{X, Z, Y) 

Observe that the equivalent and heuristically more appealing solution 
{X, Y) ^ cons{X, Z, Y), const[]{Z) 

is not obtainable since it is not a well-moded program. However, this solution is 
obtainable if the well-modedness requirement is abandoned locally in the above 
clause for synxmake. 

Various heuristics may be introduced to the program for instance exploiting 
[and(P,Q)lC |P]. 
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5.4 Synthesis with Would-be Appeal to Predicate Invention 

Let us conclude by synthesizing naive -reverse from the test suite 
[[[],[]], [[«],[«]], [[a,b],[b,a]]]. 

When the search process comes across the term 
make [2, S]{foldr{Pl, Ql)) 

from the example [[], []] may be obtained by use oi foldr the proposal 

Ql = make[l, l]{const\^) 

for the unknown subterm Ql. 

For PI is obtained by use of foldr the test suite 

[ [«: D: H]: [],Z], [a,Z, [b, o]] ]. 

Then the search process comes across the proposal 

PI = foldr{P2, Q2) 



giving at present 

maA:e[2, 3]{foldr{foldr{P2, Q2), make[l, l](const[])) 

The two first examples [a, [], [a]] and [b, [], Z] are covered by make -unit -list, 
as synthesised in sect. 5.3. This suggests the bindings Z = [&] and Q2 = 
make -unit -list, thus yielding for PI the specialization 

[KDJa]], [b,[],Z], [a,Z,[b,a]]]{Z/[b]}=[[a,[],[a\], [b,[],[b]], [a,[b],[b,a]]]. 

For P2 is in turn obtained example \b, Z' , \b, a]] for which cons can be synthe- 
sized. 

The resulting term is 

make[2, 3](foldr(foldr{cons, make -unit -list), make[l, l](const[|)) 

It would be natural to include make -unit -list in a library as a given predicate. 
Observe that without the example [[a], [a]] the synthesis process would not 
have succeeded since this hardly suffices for inducing appropriate argument pred- 
icates Q2 and P2. 

6 Conclusions 

We have outlined principles for inductive synthesis of logic programs based on 
composition of building blocks in the form of logical combinators, including 
recursion combinators. Our approach carries out the synthesis as a top down 
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composition of the combinators guided by the given test suite, but without 
generalizing program elements from the test suite. 

One advantage of the combinatory approach is that no explicit predicate 
invention is called for within the range of the considered /oW-expressible class of 
well-moded programs. Moreover the combinators avoid technical complications 
in metaprogramming with object language variables. 

Validation of feasibility of the CombInduce method vis-a-vis other ILP 
methods is awaiting experimental studies to be reported in coming papers. The 
considered examples show that trivial examples may be awkward in our method 
whereas non-trivial examples from the view of ILP like append are easy. Of 
course many trivial examples could be coped with more easily by inclusion of an 
appropriate library of non-primitive predicates. However, in this paper we have 
stressed the principles of our method, leaving heuristic tuning of the system as 
future work. 

We also plan to extend the range of considered programs by including divide- 
and-conquer combinators cf. ^ as entertained e.g., in Dialogs 0. 
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Abstract. In this paper we present a program specialisation method 
which, given a call/post specification, transforms a logic program into a 
weakly call- correct one satisfying the post-condition. 

The specialisation is applied to specialised partially correct programs. 
This notion is based on the definition of specialised derivation which is 
intended to describe program behaviour whenever some properties on 
procedure calls are assumed. Top-down and bottom-up semantics of spe- 
cialised derivations are recalled. 



1 Introduction 

Specialisation methods allow to restrict a program to a narrower context of 
application. The aim is that of obtaining a more efficient program which behaves 
as the original one on the considered subdomain. 

In the field of logic programming, the narrowed context is usually described 
by means of a set of queries of interest. Specialisation methods are based on the 
idea of partially evaluating program clauses with respect to this set 

of queries. The goal is to detect clauses which are redundant in the restricted 
context, or to specialise them preventing costly failing derivations. If the original 
program is correct with respect to a pre/post specification and the 

considered queries satisfy the precondition, then the correctness of the specialised 
program is ensured. Nothing is guaranteed on the queries which are not in the 
set of interest. They may succeed with “wrong” answers, produce a finite failure 
or an infinite computation. We simply do not care about them. 

The specialisation that we propose in this paper restricts the search space 
of a program to the set of derivations satisfying the property that, at each step, 
the selected atom “respects” a given call-condition. The main feature of our 
specialisation is that if the original program is “correct” (we say, specialised 
partially correct) with respect to a call/post specification then the specialised 
program is (partially) correct for all queries. The execution of a query which 
does not satisfy the specification ends with a finite failure. 

As an application, our approach allows us to support types without the need of 
augmenting programs with any kind of type declaration. 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 159-^^1999- 
(c) Springer-Verlag Berlin Heidelberg 1999 
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To give an intuition, consider the program SUM defined by: 
sum (X,0, X) ^ . 

sum (X, s(V), s(Z)) ^ sum (X, Y, Z). 

The intention is that of defining the sum between natural numbers which 
are represented by the constants 0, s(0), s(s(0)) and so on. However, there are 
queries like sum (a, s(0), s(a)) which succeed even if some arguments are not 
numerals. In order to avoid such “wrong” solutions, one can make use of type 
checking predicates defined by additional Prolog procedures 
Our specialisation can be used to solve this problem by restricting the program 
to a suitable context of application that is expressed in the form of a call/post 
specification. Similarly to classical pre/post specifications, a call/post specifi- 
cation consists of two parts, a call-condition and a post-condition. While the 
notion of post-condition is the standard one, the notion of call-condition used in 
this paper is not standard. It represents an invariant property that is required 
to be satisfied by atomic queries after the unification with the input clause. 
Going back to the example above, consider the call-condition characterizing all 
atoms of sum where the last argument is 

• either the constant 0, 

• or a term of the form s(_). 

Consider also the post-condition denoting all atoms of sum whose arguments are 
natural numbers with the third one being the sum of the first two. Hence, 

Call = {sum (ti, V, 2 ) | u, u are terms and 2 is either 0 or a term of the form s(_)} 
Post = {sum (u, V, z) \u,v,z are natural numbers and z = u + v\ 

By applying our specialisation transformation we obtain the specialised program: 

sum (0, 0, 0) . 

sum (s(X), 0, s(X)) V- . 

sum (X, s(F), s{Z)) ^ sum (X, F, Z). 

We do not enter into the details of the specialisation here. We just observe 
that it is applied to the head of clauses. The specialised program called with the 
query sum (a, s(0), s(a)) fails. Moreover, it produces correct answers for any non 
failing input query. 



Summarizing, in this paper we present a program specialisation which, given 
a call/post specification, transforms a logic program into a weakly call-correct 
one satisfying the post-condition. More precisely, the specialised program meets 
the following requirements: for any execution, 

• each selected atom unified with the head of the input clause satisfies the 
call-condition; 

• and each computed instance of a query satisfies the post-condition. 



The specialisation is applied to so-called specialised partially correct programs. 
This notion is a generalization of the well-known concept of partially correct pro- 
gram It is based on the definition of specialised derivation which 
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is a derivation where all the selected atoms are instantiated in order to satisfy 
a given call-condition. Thus, a specialised partially correct program satisfies the 
property that all its successful specialised derivations produce answers satisfying 
the post-condition. Specialised derivations has been introduced in Q where we 
show that they can be computed both by a top-down and a bottom-up construc- 
tion, in the style of the s-semantics We recall here such semantics. The 

equivalence of these two semantics can be proven by using the standard seman- 
tics of specialised programs as a link between them. The specialised semantics 
is useful to reason on the notion of specialised partial correctness. In partic- 
ular it allows us to provide a sufficient condition to prove that a program is 
specialised partially correct with respect to a given call/post specification. It 
consists in one application of the specialised immediate consequence operator to 
the post-condition. 

The paper is organized as follows. Section H recalls some basic notations 
and concepts. In Section ^specialised derivations and their semantics are pre- 
sented. In SectionHour program specialisation is introduced. Section^discusses 
the equivalence between the top-down and the fixpoint semantics of specialised 
derivations. In Section H^e provide a method for verifying specialised partial 
correctness of programs. Finally, in Section^we discuss a meaningful example. 



2 Preliminaries 



The reader is assumed to be familiar with the terminology of and the basic 
results in the semantics of logic programs 

Let T be the set of terms built on a finite set of data constructors C and a 
denumerable set of variable symbols V. Variable-free terms are called ground. 

A substitution is a mapping 9 -.V ^ T such that the set D{9) = {A| 9{X) ^ X} 
{domain of 9) is finite. For any expression E, we denote by 9\e the restriction of 
9 to the variables in Var{E). e denotes the empty substitution. 

The composition 9 <j of the substitutions 9 and a is defined as the functional 
composition, i.e., 9a{X) = a{9{X)). The pre-ordering < (more general than) on 
substitutions is such that 0 < cr iff there exists 9' such that 99' — a. We say that 
9 and a are not comparable if neither 9 < a nor a < 9. 

The result of the application of a substitution 0 to a term t is an instance of t 
denoted by t9. We define t < t' iS there exists 9 such that t9 — t' . We say that 
t and t' are not eomparable if neither t < t' nor t' < t. The relation < on terms 
is a preorder. We denote by w the associated equivalence relation {variance). A 
substitution 0 is a unifier of t and t' if t9 = t'9. We denote by mgu{ti,t 2 ) any 
idempotent most general unifier {mgu, in short) of ti and ^ 2 - The definitions 
above are extended to other syntactic objects in the obvious way. 



2.1 Programs and Derivations 

Atoms, queries, clauses and programs are defined as follows. Let "P be a finite 
set of predicate symbols. An atom is an object of the form p{ti, . . .fin) where 
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p G "P is an n-ary predicate symbol and ti, . . G T. A query is a possibly 
empty finite sequence of atoms Ai, . . . , Am- The empty query is denoted by □. 
We use the convention adopted by Apt in | and use bold characters to denote 
sequences of atoms. A clause is a formula i? <— B where H is an atom, called 
head, and B is a query, called body. When B is empty, i? <— B is written H ^ 
and is called a unit clause. A program is a finite set of clauses. 

Computations are constructed as sequences of “basic” steps. Consider a non 
empty query A, B, C and a clause c. Let iL ^ B be a variant of c variable 
disjoint with A, B, C. Let B and H unify with mgu 6. The query (A, B, C)6 is 
called an SLD-resolvent of A, B, C and c w.r.t. B, with an mgu 9. The atoms B 
and B9 are called the selected atom and the selected atom instance, respectively, 
of A, B,C. We write then 



A,B,C^P.e (A,B,C)0 



and call it SLD- derivation step. iL <— B is called its input clause. If P is clear 
from the context or c is irrelevant then we drop a reference to them. An SLD- 
derivation is obtained by iterating SLD-derivation steps. A maximal sequence 



«i 



d - — Qo r p^ci Ql r P,C2 ' ' ' Qr, 



’ P,Cn 



Qn+1 



of SLD-derivation steps is called an SLD-derivation of PU {Qo} provided that 
for every step the standardization apart condition holds, i.e., the input clause 
employed is variable disjoint from the initial query Qo and from the substitutions 
and the input clauses used at earlier steps. 

The length of an SLD-derivation 5, denoted by len(S), is the number of 
SLD-derivation steps in S. We denote by Sel(S) the set of all the selected atom 
instances, one for each derivation step, of 6. If P is clear from the context, 

we speak of an SLD-derivation of Qo- SLD-derivations can be finite or infinite. 

6 0 

Consider a finite SLD-derivation S Qo =^p,ci Qi • • • =^p,cn Qn of a query 

Q Qo, also denoted by 5 Qo ' — >p,ci,...,c„ Qn (or simply S := Qo ' — > Qn) 
with 6 — 9i- ■ - 9n. If Qn = tn then 5 is called successful. The restriction of 6 
to the variables of Q, denoted by 9\q, is called a computed answer substitution 
{c.a.s., in short) of Q and Q9 is called a computed instance of Q. If Q„ is non- 
empty and there is no input clause whose head unifies with its selected atom, 
then the SLD-derivation 5 is called failed. 



2.2 Interpretations 

By the extended Herbrand base we mean the quotient set of all the atoms 
with respect to w. The ordering induced by < on will still be denoted by <. 
For the sake of simplicity, we will represent the equivalence class of an atom A 
by A itself. An interpretation I is any subset of B^ . 

We recall from some definitions of useful operators on interpretations. 
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Definition 1. (Operators on Interpretations) Let I be an interpretation. 

The upward closure of I is the set 

\I] ={AgB^ \ 3A' eI,A’ < A}. 

The set of ground atoms of I is the set 

yi] = {A ^ I \ A is ground}. 

The set of minimal elements of I is the set 

Min{I) = {A&I\\/A' if A' <A then A = A'}. 



Example 1. Let I be the set {append(u, v, z) \ u,v are terms and z is a list of at 
most n elements}. Then 

Min{I) = {append Ys, [ ]), 

append Ys, 

append {Xs,Ys, [Zi, Z 2 ]), 

append Y«, [Zi, ^ 2 , • ■ • , 2'„])} 

where Xg, Yg, Zi, Z 2 , ■ ■ . , Z„ are distinct variables. 

Let us introduce the notation [/] as a shorthand for Note that [/] is the 

set of all ground instances of atoms in /. Moreover (see [d] = \Min{I)~\ 

and Min{\I~\) = Min{I). 

The notion of truth extends the classical one to account for non-ground formulas 
in the interpretations. 

Definition 2. (^) Let I be an interpretation and A be an atom . Then 

I^AiffAG \I^. 

Moreover, if Q := Ai, . . ., A„ is a query then 

I \=Q iff Ai& {/] for all i G {1, . . .,n}. 

The following properties hold Q: L \= A lA there exists A' G I such that A! < A; 
moreover, ii L \= A then for all A! such that A < A' , I \= A' . 

Definition 3. (Minimal Instances of an Atom Satisfying I) Let I be an inter- 
pretation and A be an atom. The set of minimal instances of A satisfying I is 



Mini{A) = Min{{A' G \A] \ L ^ A'}). 
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Example 2. Consider the interpretation I of the Example^ Then 

Mm/(append ([ ], Ys, Z^)) = {append ([ ], Ys, []), 

append ([],Ys,[Zi]), 
append ([],Ys,[^i, 2 ’ 2 ]), 

append ([ ], Y«, [Zi, Z 2 , . . . , Zn])} 

where Yg, Zi, Z 2 , ■ ■ ■ , Zn are distinct variables. Note that although I is infinite, 
in this case both Min{I) and Mm/(append ([ ], Yg, Zg)) are finite sets of atoms. 

The notion of specialised unifier is introduced. It is the basic concept upon which 
specialised derivations are defined. 

Definition 4. (Specialised Unifiers) Let I be an interpretation and Ai and A 2 
be atoms. A /-unifier of A\ and A 2 is a substitution 9 such that Ai9 — A20 and 
I 1= Ai9. A most general /-unifier of A\ and A 2 , denoted by 

mguj{Ai,A2), 

is any idempotent I -unifier 6 such that for any other I -unifier 8' , either 9 < 6' 
or 9 and 9' are not comparable. 

For the sake of simplicity, we will write 9 = mguj{Ai, A 2 ) even if mguj{Ai, A 2 ) 
is not uniquely determined and can even denote an infinite set of substitutions. 



Example 3. Consider again the interpretation I of the Example^ Then 
m 5 Uj(append (//, V, W), append ([],//«, -^s)) 
denotes the following substitutions 

9^={U/[lV/Xg,W/Xg,Xg/[]} 

01 ={U/[fVIXg,WIXg,Xgl[Zf^} 

02 ={U/[\,VIXg,WIXg,Xgl[Z^,Z2\} 

9n = {U/[ fV/Xg, WIXg,Xg/[Z^, Z 2 , . . . , Zn]}. 

Note that the substitutions 0 q, 0i, . . . , 0n are pairwise not comparable. Moreover, 
they are idempotent but not relevant with respect to the variables occurring 
in the two unifying atoms. In fact, they contain new variables, |Zi,...,Z„}, 
which are introduced in order to satisfy /. We call these variables place holders. 
Note that the definition of specialised most general unifier imposes that they are 
pairwise disjoint and distinct from the variables occurring in the unifying atoms. 

It is well known that set inclusion does not adequately reflect the property 
of non-ground atoms of being representatives of all their ground instances. So, 
in this paper, we refer to the partial ordering C on interpretations defined by 
Falaschi et al. in as below. 
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Definition 5. Let Ii and I2 be interpretation. 

• h < h ijjyAi G 7 i, 3^2 £ I2 such that A2 < Ai. 

• Ii Q I2 iff {Ii < I2) and {I2 < h implies Ii C I2). 

Intuitively, ff < I2 means that every atom verified by Ii is also verified by I2 
{I2 contains more positive information). Note that < has different meanings for 
atoms and interpretations. I\ C I2 means either that I2 strictly contains more 
positive information than ff or that the amount of positive information is the 
same and I\ expresses it by fewer elements than The relation < is a preorder, 
whereas the relation C is an ordering. Moreover, if /i C /2, then ff C ff. 

Example 4 - Consider the interpretation I of the Example^ Then I < Min{I), 
but also Min{I) C /. Moreover, Mm/(append ([ ], Tg, Zg)) E Min{I). 

The set of all the interpretations X under the relation C is a complete lattice. 

Proposition 1. The set of interpretations X with the ordering Q is a com- 
plete lattice, notec^^ (X, C) • is the top element and 0 is the bottom element. 

3 Specialised Derivations and their Semantics 

In this section we recall from Q the notion of specialised derivation and show 
some properties. Top-down and a fixpoint semantics are presented. 



3.1 Specialised Derivations 

Given an interpretation I, a specialised derivation is an SLD-derivation where 
all the selected atoms are instantiated in order to satisfy the call-condition /. 
Specialised derivations are defined as SLD-derivations except that at each deriva- 
tion step specialised most general unifiers are computed instead of usual mgus. 
In the following we assume given a program P. 

Definition 6. Let I be an interpretation. Let A, B,C be a non empty query, 
c be a clause, H B be a variant of c variable disjoint with A,B,C. Let B 
and H unify and 9 = mguffB, H) where the place holders of 9 are disjoint from 

A, B,C. The query (A,B,C)0 is called an /-resolvent of A,B,C and c w.r.t. 

B, with specialised mgu 9. The atoms B and B9 are called the /-selected atom 
and /-selected atom instance, respectively, of A, B,C. We write then 

A,B,C=Up,,j (A,B,C)0 

and call it /-derivation step. // ^ B js its /-input clause. A maximal sequence 



h • — Qq P,c\ ,I Ql P,C2 ,/ ‘ ‘ ‘ Qn P,Cn+i ,I Qn+l 

of I -derivation steps is called an /-derivation of PU {Qo} where for every step 
the I -standardization apart condition holds, i.e., the I -input clause Ci employed 
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and the place holders of unifier 9i are variable disjoint from the initial query Qo 
and from the substitutions and the input clauses used at earlier steps. 

We denote by Sel{6) the set of all the I-selected atom instances of 6. 

Consider a finite I -derivation S := Qo =^p,ci,/ Qi ■ ■ ■ =^p,cn,i Qn of a query 

Q Qo, also denoted by 5 Qo ' — Qn (or simply S := Qo ' — >i Qn) 

with 0 = 0i ■ ■ ■ On- If Qn — then 6 is called successful. The restriction of 9 to 

the variables of Q is called a /-computed answer substitution (I-c.a.s., in short) 
of Q and Q9 is called a /-computed instance of Q. If Qn is non-empty and there 
is no I -input clause // <— B such that H unifies with the I-selected atom B of 
Qn with 9 — mguj{B, H), then 5 is called failed. 

Whenever I is omitted, we assume that / = It is easy to see that if I is 
the extended Herbrand base , then /-derivations (resp. /-derivation steps) 
are indeed SLD-derivations (resp. SLD-derivation steps). 

Example 5. Consider the interpretation I of ExampleH^nd the program APPEND: 
append ([],Xs,Xs) ^ . 

append ([//l/fs], Ys, [//|Zs]) ^ append {Xs,Ys,Zs). 

Let 9o,9i, . . .,9n be the substitutions defined in the ExampleH Then 

append {U, V, W) □ 

append {U, V, W) □ 

append {U, V, W) □ 

are successful /-derivations of the query append [U,V,W). Note that any /- 
derivation of the query append ([ ], f oo, f oo) fails. 

Observe that, for any /-derivation 5, Sel{6) < /, i.e., for all A s Sel{6), I \= A. 
Moreover, any SLD-derivation 6 satisfying Sel{6) < / is an /-derivation. 

The following relation between successful I and SLD-derivations holds. 

n 0 

Let I be an interpretation and S := Q i — >ci,...,c„,/ ^ be a suc- 
cessjul 1 -derivation of a query Q. Then, there exists a successful SLD-derivation 
S' := Q9 of Q9 with Q9^ = Q9 and Sel{5') < Sel{5). 

The next result is useful to reason on /-derivations. 

Lemma 2. Let I be an interpretation and 5 := Q i — »/ O be a successful I- 
derivation of a query Q := Ai, . . . , A„. Then, for all j G {1, . . . , n}, there exists 
a successful I-derivation Sj := Aj9 □ where Aj9^j = Aj9. 

Proof. Let S := Q i — >i □. By LemmaH there exists a successful SLD-derivation 
S' Q9 i-dU □ with Q9^ — Q9 and Sel(S') < Sel{S). By properties of SLD- 
derivations (see ^^^3), for all j G {1, . . .,n}, there exists a successful SLD- 
derivation Sj Aj9 □ such that Aj9jj = Aj9 and Sel{Sj) < Sel{S'). Then, 
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for all j e Sel{6j) < Sel{6). Moreover, since 6 is an /-derivation, 

Sel{6) < I. Hence, for all j € {1, . . .,n}, Sel{5j) < I and then, by Definition^ 

5j is a successful /-derivation AjO i-^i □. 



We show that any /-computed instance is true in I. 

Q 

Lemma 3. Let I be an interpretation and 5 := Q i — O be a successful /- 
derivation of a query Q. Then I ^ Q6. 



Proof. Let Q := Ai, . . . , We prove that for all j € {1, . . . , n}, I [= AjO. 

By LemmaH for all j € n}, there exists 6j := AjO □ where AjOjj = 

Aj9. Let Hj be the head of the /-input clause used in the first /-derivation step of 
6j. Let also yj = mguj{Aj6, Hj). By Definition^ I \= and by Definition^ 
If ^3^1 3 - Hence, by Definition H I \= Ajdjj. 

The Lifting Lemma for SLD-derivations can be generalized to specialised 
derivations as follows. 



Lemma 4. (Specialised Lifting Lemma) Let I be an interpretation and S := 
Q6 U be a successful I -derivation of a query Q6. Then, there exists a 

successful I -derivation S' := Q □ where o' < 9a. 

Proof. By induction on len{6). 

Basis. Let len{S) = 1. In this case Q consists of only one atom B and 



5 :=B9 



□ 



where // <— is the /-input clause and a = mguj{B9, H). Because of standardi- 
zation apart, we can assume that 9\h = £• Then, 9a is a /-unifier of B and H. 
Hence, there exists a' = mguj{B, H) such that a' < 9a and 



5' -.= B 




□ 



is a successful /-derivation. 

Induction step. Let len{6) > 1. Then Q := A, B, C and 

S := (A, B, C)9 (A, B, C)9ai □ 

where B is the /-selected atom of Q, c :=//<— B is the first /-input clause, 
a\ — mguj{B9, H) and a — a\a 2 . Because of standardization apart, we can 
assume that 9^^ = e. Then, 9ai is a /-unifier of B and H. Hence, there exists 
a'l = mguj{B, H) such that a'^ < 9a\ and 

(A,i?,C) (A,B,C)a'i 

is an /-derivation step. Let 7 be a substitution such that <7(7 = 9a\. By the 
inductive hypothesis, there exists a successful /-derivation 

(A,B,C)a;^,D 
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where a'2 < 7CT2. Therefore, 

(5' := (A, C) (A, B, C)al ^7 □ 

is a successful /-derivation. Let a' = Then, 

o' = cr^CT2 (by definition of a') 

< a'i')(J2 (since a'2 < ')<J2) 

— 0a\a2 (since ct(7 = Oai) 

= 8 a (by definition of a). 



3.2 Specialised Top-down Semantics 

We present below a top-down construction which computes the specialised se- 
mantics of logic programs. It models the computed answer substitutions of the 
specialised derivations. 

Definition 7. (Specialised Computed Answer Substitution Semantics) Let P 
be a program and I be an interpretation. The /-computed answer substitution 
semantics of P is 

Oi{P) = {A € I € P, 3Ai, . . . , Xn distinct variables in V, 30, 

p(Ai,...,A„)^p, 7D, 

A = p(Ai,...,A„)0}. 

Observe that if I is the extended Herbrand base , then 0 ]ge{P) is the original 
s-semantics defined by Falaschi et al. in Q. 

Example 6 . Consider the interpretation I of Example J Then 

07(APPEND) = {append ([],[],[]), 

append ([], [Xi], [Ai]), 
append ([], [Ai, A2], [Ai, A2]), 

append ( [ ] , [ Ai , A2 , . . . , A„] , [ Ai , A2 , . . . , A„] ) , 
append ([Ai], [], [Ai]), 
append ([Ai],[A2],[Ai,A2]), 

append ( [Ai] , [A2 , . . . , A„] , [Ai , A2 , . . . , A„] ) , 
append ([Ai,A2],[],[Ai,A2]), 



}■ 



Let us consider now the success set and the non-ground success set semantics 
formally defined in The corresponding specialised versions are defined below. 

Definition 8 . (Specialised Success Set Semantics) Let P be a program and / be 
an interpretation. The /-success set semantics of P is defined by 



Oip{P) = {A & \ A is ground and A 



7 



j □ where A'y = A}. 
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Note that if I is the extended Herbrand base , then ^(P) is the standard 
semantics, which is equivalent to the least Herbrand model 

Definition 9. (Specialised Non-ground Success Set Semantics) Let P be a pro- 
gram and I be an interpretation. The /-non-ground success set semantics of P is 
defined by 

Oi, 2 {P) = {A G \ A □ where A'y = A}. 

If I is equal to B^ , then 0^e^2{P) is the set of atomic logical consequences 0 of 

P. 

It is easy to prove that the following relations hold: Oj i{P) = [Oi{P)] and 
Op2{P)^\Oi{P)]. 

3.3 Specialised Fixpoint Semantics 

We define an immediate consequence operator Tp j on the set of interpretations 
I. Its least fixpoint has been shown to be equivalent to the specialised computed 
answer substitutions semantics 0/(P). 

Definition 10. (Ppj Transformation) Let P be a program and I and J be two 
interpretations. 

Tp,i{J) = {H € I ^ Pi, . . ,,P„ € P, 

3P( , . . . , P(j variant of atoms in J and renamed apart, 

36 = mguj{{Bi ,. . .,P„), {B {, . . .,P(,)), 

A e Mini(B6)}. 

Note that if L is the extended Herbrand base B^, then Tp ^e coincides with the 
S-transformation Pg defined in ^ 3 . 

Proposition 2. (Monotonicity and Continuity of Tpj) For any interpretation 
I, transformation Tpj is monotonic and continuous in the complete lattice {I, C 

)• 



Definition 11. (Powers of Tpj) As usual, we define powers of transformation 
Pp,i follows: 

Tpj TO =0, 

Tpj t n -I- 1 = Tpj {Tpj T n), 

Tpj f = [Jn>oiTpj T n)- 

Proposition 3. For any interpretation I, Tpj f uj is the least fixpoint of Tpj 
in the complete lattice {J, □) . 

Proof. By Proposition J Tpj | w is the least fixpoint of Tpj with respect to 
set inclusion. Moreover, for any fixpoint J of Pp/, Tp j f u> C J. Hence, by 
DefinitionH Tpj T w C J. 

The specialised fixpoint semantics is formally defined as follows. 

Definition 12. (Specialised Fixpoint Semantics) Let P be a program and L be 
an interpretation. The /-fixpoint semantics of P is defined as 

Fi{P) = Tpj T w. 
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4 Specialising Programs wrt Call/Post Specification 

In this section we define a simple program transformation which given a call / post 
specification transforms a program into a weakly call-correct one satisfying the 
post-condition. The notion of weak call-correctness is formally defined as follows. 

Definition 13. (Weak Call-correctness) Let P be a program and I be an inter- 
pretation. We say that P is weakly call-correct with respect to the call- condition 
I iff for any query Q and SLD- derivation S of PU {Q}, Sel{S) < I. 

Our specialisation is applied to so-called specialised partially correct programs 
which are introduced below. 



4.1 Specialised Partially Correct Programs 

In this section we introduce the concept of specialised partially correct program 
with respect to a given call/post specification. It provides a weaker notion of 
partial correctness where specialised derivations only are observed. In Section^ 
a simple method for verifying specialised partial correctness will be presented. 

Definition 14. Let P be a program and Call and Post be interpretations. We 
say that P is specialised partially correct (s.p.c., in short) with respect to the 
call- condition Call and the post- condition Post, noted 

{Call}P{P0St}spec, 

if and only if for any query Q, 

Q ' — ^p,Caii n implies Post ^ Q6. 

Observe that, if Call — then P is correct with respect to the post-condition 
Post according to the standard correctness definition. In this case, P is s.p.c. 
with respect to any call-condition Call and the post-condition Post. 

Example 7. Consider the program APPEND and the interpretations 

Call = {append (u, v, z)\u,v are terms and z is a list of at most n elements} 
Post = {append (rt, v, z) \ u,v,z are lists, .z has at most n elements and z = u*v} 

where * is the list concatenation operator. The program APPEND is s.p.c. with 
respect to the specification Call and Post, i.e., the following assertion holds: 

{Call} APPEND {Post} spec- 

We define the strongest post-condition of a program P with respect to a given 
call-condition as follows. 

Definition 15. (Strongest Post-condition) Let P be a program. The strongest 
post-condition of P with respect to a call-condition I, noted sp{P,L), is the 
smallest interpretation J with respect to □ such that {I}P{J}spec- 
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The next Proposition characterizes the strongest post-condition of a program P 
wrt a call-condition I in terms of the 7-c.a.s. semantics of P. 

Proposition 4. Let P be a program and I he an interpretation. 

Then, Min{Oi{P)) = sp{P,I). 

Proof. We prove that {I}P{Min{Oi{P))}spec holds, i.e., if 6 := Q □ is a 
successful /-derivation of a query Q then Min{Oi{P)) ^ Q6. 

Let Q ■.= Ai, . . ., An. By LemmaO for all j G {1, . . . , n} there exists a successful 
/-derivation 6j := Aj9 □ where Ajdjj = AjO. For all j G {1, . . .,n}, let 
Pj G V and Xi, ... , Xn be distinct variables in V such that Pj{Xi , . . . , Xn) < 

AjO. By LemmaO there exists a successful /-derivation pj{Xi , . . . , Xn) < — □ 
where pj{Xi, ..., Xn)0j < AjO. By Definition H G 

This proves that for all j, Min{Oi{P)) |= Aj9 and then Min{Oi{P)) |= QO. 

Further, for any interpretation J such that {I}P{J}spec, Min{Oi{P)) C J. 
We first prove that Min{Oi{P)) < J, i.e., for all A G Min{Oi{P)) there exi- 
sts A' G J such that A' < A. Let A G Min{0[{P)). By Definition ^ there 
exist p G V , Xi, ... , Xn distinct variables in V and a substitution 9 such that 

p{Xi , . . . , Xn) I — >i □ is a successful /-derivation and A = p{Xi , . . . , Xn)9. By 
the hypothesis {I}P{J}spec, J A. So, there exists A' G J such that A' < A. 
Suppose now that J < Min{Oi{P)). Then Min{Oi{P)) C J. Indeed, from the 
fact that both Min{Oi{P)) < J and J < Min{Oi{P)), for all A G Min(Oj(P)) 
there exists A' G J and A” G Min{Oi{P)) such that A” < A’ < A. By Defini- 
tion^of operator Min, A" = A and then A G J. 



4.2 Specialised Programs 

Any s.p.c. program P with respect to a given call/post specification I and J, i.e., 
such that {I}P{J}spec holds, can be transformed into a specialised program Pj 
which is weakly call-correct with respect to the call-condition I and satisfies the 
property {B^}Pi{J}spec- This means that for any query Q and SLD-derivation 
6 of Pi U {Q} with computed answer substitution 9, Sel{6) < I and J ^ Q9. 

Specialised programs are obtained from the following program transformation. 

Definition 16. (Specialised Program) Let P be a program and / be an inter- 
pretation. The /-program corresponding to P, denoted by Pi, is defined as: 

Pi = {{H ^B)-f\ H G P and i/y G Mim{H) 
where 7 is idempotent and 
Var( 7 ) n Var{H v- B) C Dom{'j) = Var{H)}. 

The condition Var( 7 ) n Var{H B) C Domf-f) = Var{H) allows us to avoid 
undesired bindings on the variables in the bodies. 

Note that Pi may be an infinite program but it will be finite whenever Min (I) 
is finite. 
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Example 8. Consider the program APPEND and the interpretations Call and Post 
given in the Example^ The specialised program APPENDcon is defined by: 

append ([],[],[])■ 
append ([], [Xi], [Xi]). 
append ([],[Xi,X2],[Xi,X2]). 

append ( [ ] , [Xi , X2 , . . . , Xn ] , [Xi , X2 , . . . , Xn \ ) . 
append ([XiIXs], Ts, [-^1]) ^ append [])■ 

append ([Xi|X«], [Xi, X2]) ^ append F,, [X2]). 

append ([Xi|X«], F«, [Xi, X2, . . . , XJ) ^ append F«, [X2, . . . , X„]). 

It is easy to see that the assertion {B^} APPENDcan {Post}spec holds, meaning 
that for any query Q and successful SLD-derivation 5 of APPEND con U {Q} with 
computed answer substitution 0, Post \= Q9. Moreover, for any selected atom 
instance A G Sel{S), Call |= A. Hence, Sel(S) < Call. 



Proposition 5. Let P be a program and I be an interpretation with {I}P{J} spec- 
Then, Pj is weakly call-correct with respect to I. 

Proof. Let 6 be an SLD-derivation of P/. We prove that for all A £ Sel{6), 
I \= A. Indeed, for all A € Sel{6) there exists and SLD-derivation step 

A,P,C^P,,g. (A,B7,C)0 

of 6 where B is the selected a tom , {H <— 6)7 is the input clause, 9 = mgu{B, Hj) 
and A = B9. By Definition P ^ B is a variant of a clause of P such that 
Hj G Mini{H). Hence, I h H-f9 ^ B9 = A. 



Proposition 6. Let P be a program and L be an interpretation. 

Then, P spec implies ^B ^Pi\^jyspec- 

Proof. We need the following result. 

Claim. I Let P be a program, Q := A, P, C and I be an interpretation. If 

A,P,C^P,,g. (A,B,C)0 

is an SLD-derivation step then there exists a substitution 7 such that 

A,P,C^P7 (A,B',C)70 

is an /-derivation step where B = B '7, (A, B, C)9 = (A, B', C)70 and 7 |q = e. 

Suppose that {I}P{J}spec holds. We prove that for any query Q and success- 
ful SLD-derivation S := Q 1 — Q^- order to obtain this result, we 
prove that for any such 5, there exists a successful /-derivation 5' := Q9 >-^pj □ 
where Q9a — Q9. The fact that J \= Q9 follows by the hypothesis {I}P{J}spec- 
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This is done by induction on len{5). 

Basis. Let len{6) = 1. In this case, Q consists of only one atom B and 

S := B □. 

By Claim^J there exists a substitution 7 such that 

B =^p,i □ 

is an /-derivation step and 7 |s = e. By LemmaH it follows that 

5' := Be = B-fO ^pj □ 

is a successful /-derivation of B9 where BOa = B9. 

Induction step. Let len{5) > 1. In this case Q := A, B, C and 

<5 := A, B, C ^Ppse (A, B, 0)9, □ 

with 9 — 9,92. By Claim^Hthere exists a substitution 7 such that 

A,B,C^Pj (A,B',C)70i 

is an /-derivation step where B = B' 7 , (A, B, 0)9, = (A, B', 0 ) 7^1 and 7 |q = e. 
Let // ^ B' be the input clause and 7^1 = mgu{B, H). Then, by properties of 
substitutions ^ there exists a substitution a, such that cr,\Qg = e, 
and a, — mguj{B9, H). So, 

(A, B, 0)j9 ^p.i (A, B', C)70ai 

is an /-derivation step. Since 7 |q = e and (A, B, 0)9, = (A, B', C) 70 i, also 

{A,B,0)9^Pj (A,B,C)0ai 
is an /-derivation step. By the inductive hypothesis, 

(A,B,C)0 ^p7 D 

is a successful /-derivation where (A, B, 0)9(J2 = (A, B, 0)9. Moreover, 

(A, B, 0)9 = (A, B', 0)j9 (since (A, B, 0)9, = (A, B', 0 ) 76 * 1 ) 

= A9, B' 70 , 09 (since 7 |q = e) 

= A9, B' 70 (Ti, 09 (since 70 |p_b' = and a, is idempotent) 

= A9, B0(Ji, 09 (since B = B' 7 ) 

= (A, B, 0)9a, (since a,\Qg = e). 

Then, 

(5' := (A, B, 0)9 ^pi (A, B, 0)9a, ^pj □ 
is a successful /-derivation. Let a = a, a 2 . Then 

Q9a = (A, B, 0)9(7, cr 2 (by definition of Q and of cr) 

= A9a2, B9a2, 09u2 (since (7,\Qg = e) 

= A9, B9a2, 09 (by inductive hypothesis) 

= A9, B9, 09 (because of standardization apart) 

= Q9 (by definition of Q). 
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5 Equivalence of the Top-down and Fixpoint Semantics 

In this section we discuss the equivalence between the specialised top-down se- 
mantics Oi{P) and the fixpoint semantics The reader is referred to Q 

for more details. The proof follows from the fact that for any program P and 
interpretation I, both Oj{P) — 0{Pj) and Pi{P) — P{Pi) hold. 

The equivalence between Oi{P) and 0{Pi) follows from the following result. 

Proposition 7. Q Let P be a program and I be an interpretation. Then, there 
exists a successful SLD-derivation 5 := Q O of a query Q iff there 

Q> 

exists a successful I -derivation S' := Q i — >pj □ where Q9 = Q6' . 

Theorem 1. For any program P and interpretation I, 0{Pj) = Oj{P). 

Proof. Recall that 0{Pi) = 0^e{Pi). The result follows from Proposition^ 

The next Proposition relates powers of transformations Tp^ j^s and Tp j. It allows 
us to prove the equivalence between Pi{P) and tF{Pi). 

Proposition 8. D Let P be a program, L be an interpretation and A be an 
atom. Then for aMn > 0, d S Tpj jgs 1 n iff A G Tp j 1 n. 



Theorem 2. For any program P and interpretation I, tF{Pi) = Ti{P). 

Proof. Recall that tF{Pi) = J-se(Pi). The result follows from Proposition^ 

We are now in position to prove the equivalence between the specialised top- 
down and fixpoint semantics. 

Theorem 3. (Equivalence of Specialised Top-Down and Fixpoint Semantics) 
For any program P and interpretation I, Oi{P) = !Fi{P). 

Proof. By 0{Pi) = tF{Pi). The result follows from TheoremsJandJ 

6 Verifying Specialised Partial Correctness 

In this section, we show that the specialised partial correctness of a program with 
respect to a given call/post specification can be verified just by one application of 
the specialised immediate consequence operator Tpj to the given post-condition. 

Let us first prove the following sufficient condition. 

Lemma 5. Let P be a program and L and J be two interpretations such that 
sp{P,I) C J. Then, {I}P{J}spec holds. 
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Proof. We prove that for any query Q and successful /-derivation S := Q i — >/ □, 
J 1= Q6. Let Q := Ai, . . . , An. We show that for all j G {1, . . ., n}, J ^ Aj9. 

By LemmaH for all j G {1, . . . , n}, there exists a successful /-derivation Sj := 

AjO i-^i □ where Ajd^j = AjO. Let pj G V and X\, . . ., Xn be distinct vari- 
ables in V such that pj{Xi ^ . . . , Xn) < AjO. By LemmaH for all j, there exists 

& 

a successful /-derivation Pj{Xi , . . . , Xn) ' — n where pj{Xi , . . . , Xn)0j < AjO. 
By DefinitionHpj(Xi, . . . , Xn)0j G Oj(P). Hence, by Proposition^ sp(P, I) ^ 
AjO. The fact that J \= AjO follows from the hypothesis that sp{P, I) C J. 

The next Proposition provides a method for verifying specialised partial correct- 
ness with respect to a given call/post specification. 

Proposition 9. Let P be a program and I and J be interpretations. Then, 
Tp,i{J) E J implies {I}P{J}spec- 

Proof. We first establish the following Claims. The proofs are given in 

Claim. Let P be a program and I and J be two interpretations. 

Then Min{Tpj{J)) = Min{Tpj{Min{J))). 

Claim. For any interpretation /, the transformation Min o Tpj is monotonic in 
the complete lattice {T, E) • 

By LemmaH it is sufficient to prove that Tpj{J) E J implies sp{P, I) E J- 
We first prove that for all n > 0, Min{Tpj '[ n) C J. 

By induction on n 

Basis. Let n = 0. Straightforward, since by Definition Min{Tpj 10) =0. 
Induction step. Let n > 0. In this case, 

Min{Tp j I n) = Min{Tp j{Tpj t ^ ~ 1)) (by Definition^J 

= Min{Tpj{Min{Tpj t u — 1))) (by ClaimH 

E Min{Tpj{J)) (by induction hypothesis and 

Claimfl 

E Tpj{J) (by DefinitonH 

E J (by hypothesis). 

It follows that Mm(U^>Q(Tpj t n)) E J- 

In fact, Min{[j^^Q(Tpj | n)) < J, i.e., for all A G Min{[j^yQ{Tpj f n)) there 
exists A' G J such that A' < A. This property follows from the fact that for all 
A G Min{\J^^g{Tpj t n)) there exists n > 0 such that A G Min{Tpj f n). As 
proved above, Min{Tpj 'I n) C J. Hence, by Definition H Min{Tpj 'I n) < J, 
i.e., there exists A' G J such that A' < A. 

Moreover, if J < d/m(|J„>Q(rpy t n)) then Min{fj^yQ{Tpj | n)) C J. In fact, 
since both d/m(lJ^>Q(Ppy f n)) < J and J < Minifj^.^Q{Tpj | n)), for all 
A G LIin((J^yg(Tpj t n)) there exists A' G J and A” G Min{\J^^^{Tpj | n)) 
such that AT < A' < A. By DefinitionOof operator Min, A" = A and then 
A G J. Therefore, 
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sp{P,I) = Min{Oi{P)) 

= Min{Pi{P)) 

= Min{Tpj t (jj) 

= t n)) 

E J 



(by Proposition J 
(by TheoremH^ 
(by Definition's 
(by Definition^J 
(as proved above). 



7 An Example 

In this section we illustrate by means of an example the specialisation method 
defined in Section Consider the program FRONT | defined below, 
front (void, [ ]). 

front (tree (X, void, void), [A^]). 
front (tree (X, L, R), Xs) <— nel_tree (tree (X, L, R)), 

front (L, Ls), 
front (i?, Rs), 
append (Ls,Rs, ^s). 
nel_tree (tree (_, tree (_, _, _), _)). 
nel_tree (tree (_, _, tree (_, _, _))). 

augmented by the program APPEND. It computes the frontier of a binary tree, 
i.e., it is correct with respect to the post-condition 

Post = {front (t, /) I / is the frontier of the binary tree t} U |nelj.ist (t)| t is 
a term} U {append (u, v, z) \ u,v,z are lists and z = u*v} 

where * is the list concatenation operator. 

The auxiliary relation nel_tree is used to enforce that a tree is a non-empty, 
non-leaf tree, i.e., that it is a term of the form tree (x, left, right) where either 
left or right does not equal void. 

Observe that the simpler program that is obtained by removing the first atom 
nel_tree {tree{X, L, R)) in the body of the third clause and by discarding 
the relation nel_tree is indeed incorrect. In fact, as shown in Q, the query 
f ront(tree(X, void, void), Xg) would yield two different answers: {Xs/[X]j by 
means of the second clause and {Xs/[ ]} by means of the third clause. 

Suppose that our application domain consists of the set of binary trees whose 
left subtrees are all leaves. This information can be expressed by means of the 
following call-condition: 

Call — {front (t, /) | t is either the empty tree or a leaf or a term of the form 
tree(u, r, s) where r is a leaf and u, s and I are termsjU 
{nelJList (t)| t is a term} U {append (u, v, z) | u,v,z are terms} 

Note that, since the program is correct with respect to Post, then it is also s.p.c. 
with respect to the call/post specification Call and Post, i.e.. 



{ Call}FKOm{Post}spec- 
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That can be also proven by computing ,Caii{Post) . We obtain 

Tmoin,Cau{Post) = {front (void, []), front (tree (X, void, void), [1^])}U 
{front (t, /) I t is a binary tree whose left subtree is a 
leaf and I is the frontier of t}U 
{nelj.ist (t) I t is a non-empty, non-leaf tree }U 
{append {u, v, z) | u,v,z are lists and z = u* v}. 

Then the program can be specialised into a weakly call-correct program FRONT 
Consider the Definition^J Observe that for all head H, different from the third 
clause head, Mincaii{H) = H, whereas, Mmcan(front(tree {X, L, R), Xs)) = 
{f ront(tree(J*f, void, void), Xg), f ront(tree(X, tree(T, void, void), i?), f*fs)}- 
The specialisation results in the program FRONT con defined by: 

front (void, [ ]). 

front (tree (X, void, void), [^]). 

front (tree (X, void, void), Xg) ^ nel_tree (tree (X, void, void)), 

front (void, Tg), 
front (void, i?g), 
append (Tg, i?g, Xg). 

front (tree (J*f, tree (T, void, void), i?), Xg) <— 

nel_tree (tree (X, tree (T, void, void), i?)), 
front (tree (T, void, void), Tg), 
front (i?, i?g), 
append (Tg, i?g, Xg). 

augmented by definitions of the relations nel_tree and append. 

Now by unfolding we obtain 

front (void, [ ]). 

front (tree (X, void, void), [^]). 

front (tree (_, tree (T, void, void), i?), [T|i?g]) f ront (i?, i?g). 

where both the relation nel_tree and the relation append are not used. 
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Abstract. In recent work, we proposed a simple functional language 
S-graph-n to study metaprogramming aspects of self-applicable online 
program specialization. The primitives of the language provide support 
for multiple encodings of programs. An important component of online 
program specialization is the termination strategy. In this paper we show 
that such a representation has the great advantage of simplifying gener- 
alization of multiply encoded data. After developing and formalizing the 
basic metaprogramming concepts, we extend two basic methods to mul- 
tiply encoded data: most specific generalization and the homeomorphic 
embedding relation. Examples and experiments with the initial design of 
an online specializer illustrate their use in hierarchies of online program 
specializers. 



1 Introduction 

Multiple levels of metaprograms have become an issue for several reasons, on 
the one hand they are a natural extension of metaprogramming approaches, on 
the other hand they have been used to great advantage for program generation. 
Multi-level metaprogramming languages that support this style of metaprogram- 
ming have been advocated, e.g. Representing and reasoning about ob- 

ject level theories is an important field in logic and artificial intelligence and 
has led to the development of logic languages that facilitate metaprogramming 
{e.g. the logic languages Godel Reflective Prolog |, A-Prolog B9)’ 

Our goal is to lay the foundations for a multi-level metaprogramming en- 
vironment that fully addresses the unique requirements of multi-level program 
hierarchies and to develop techniques for efficient computation on all levels of 
a metasystem hierarchy. The present work addresses these open issues in the 
context of S-graph-n — a simple functional language which provides primitives 
for manipulating metacode and metavariables. 

Writing meta-interpreters is a well-known technique to enhance the expres- 
sive power of logic programs QQ. The approach of applying a program trans- 
former to another program transformer — not just to an ordinary program — has 
been put to good use in the area of program specialization (a notable 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 179-^^1999- 
(c) Springer-Verlag Berlin Heidelberg 1999 
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level 0 : po : 

level 1 : pi : 

level n — 1 : Pn-i '■ 

level n : Pn : 

Fig. 1. MST Scheme of a metasystem hierarchy 



example are the Futamura projections). Common to these approaches is the 
construction and manipulation of two or more program levels. 

A metasystem hierarehy is any situation where a program pq is manipulat- 
ing {e.g., interpreting, transforming) another program pi. Program pi may be 
manipulating another program p 2 , and so on. A metasystem hierarchy can be 
illustrated using a metasystem transition scheme as in Figure Metapro- 

gramming requires facilities for encoding programs as data objects. In a meta- 
system hierarchy, such as displayed in Figure O programs may be metacoded 
many times. For example, program of FigureH^ust be metacoded (directly 
or indirectly) n times, since n systems lie above it in the hierarchy. The rep- 
resentation of programs and data has been studied especially in the context of 
logic programming Q (mostly two-level metasystem hierarchies) . 

Among others, exponential space consumption, time inefficiencies, and lack 
of representation invariance of meta-level operations are problems to be tackled. 
We now shortly illustrate some of these problems. 

Example 1. To illustrate the space consumption problem in metasystem 
hierarchies, consider a straightforward strategy for encoding S-expressions (as 
known from Lisp) where p is the metacoding function. 

^{(CDNS expi exp^)} = (CONS (ATOM CONS) (CDNS^{expi} plexp^})) 

^{(ATQM atom)} = (CONS (ATOM ATOM) (ATOM atom)) 

Using this strategy, the expression (CONS (ATOM a) (ATOM b) ) metacoded twice 
is 

/.l{/i{(CaNS (ATOM a) (ATOM b))}} = (CONS (ATOM CONS) (CONS (CONS (ATOM ATOM) (ATOM CONS)) (CONS 

(ATOM CONS) (CONS (CONS (ATOM CONS) (CONS (CONS (ATOM ATOM) 
(ATOM ATOM)) (CONS (ATOM ATOM) (ATOM a)))) (CONS (ATOM CONS) 
(CONS (CONS (ATOM ATOM) (ATOM ATOM)) (CONS (ATOM ATOM) (ATOM 
b)))))))) 

The naive encoding is straightforward, but leads to an exponential growth of 
expressions, and yields terms that are harder to reason about. In addition, var- 
ious specialization procedures {e.g., generalization algorithms) that repeatedly 
traverse metacode will suffer from a significant computational degrading effect 
as can be seen from this example. 

The area of online program transformation (e.g., partial deduction, super- 
compilation) has seen a recent flurry of activity, e.g. Recently 

well-quasi orders in general, and homeomorphic embedding in particular, have 
gained popularity to ensure termination of program analysis, specialization and 
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other program transformation techniques because well-quasi orders are strictly 
more powerful than a large class of approaches based on well-founded orders. 
Despite the progress that has occurred during the last years, metasystem hier- 
archies still pose an challenge to online transformation and metaprogramming. 

Example 2. To illustrate the invariance problem, consider the influence en- 
coding has on the termination behavior of online transformer relying on the 
homeomorphic embedding relation < defined for S-expressions: 



(ATOM a) < (ATOM 6) 

(CONS Si S 2 ) < (CDNSti t2) 
s < (CDNSti t 2 ) 



Si < U for all i £ {1, 2} 
s < ti for some i € {1, 2} 



Consider the following two terms which may occur during direct transforma- 
tion of a program (e.g., as arguments of a function or predicate). The embedding 
relation signals the transformer that it can continue: 

(ATOM ATOM) ^ (CONS (ATOM a) (ATOM a)) 

Assume that we insert an interpreter (or another metaprogram) that works 
on encoded terms. Now the embedding relation signals the transformer that it 
should stop immediately: 

^{(ATQMATQM)} < (CONS (ATOM a) (ATQMa))} 

In short, encoding the terms leads to premature termination. Ideally, a termi- 
nation condition is invariant under encoding, so that termination patterns are 
detected reliably regardless of the encoding of terms. Similar problems occur 
with other operations popular with online transformers. Existing transformers 
are only geared toward the direct transformation of programs. They often fail 
to perform well on an extra metasystem level, so that several refinements have 
been suggested, e.g. For a discussion of the invariance problem see also 

Higher-order terms provide a suitable data structure for representing pro- 
grams in a higher-order abstract syntax. Higher-order logic programming utilizes 
higher-order logic as the basis for computation, e.g. The primary advantage 
of higher-order abstract syntax is that it simplifies substitution and reasoning 
about terms up to alpha-conversion. However, we believe that there are a num- 
ber of theoretical difficulties that one would encounter when using high-order 
logic as the basis for multi-level metaprogramming. For instance, the question 
of whether or not a unifier exists for an arbitrary disagreement set is known 
to be undecidable. Moreover, extending online program transformers, e.g. par- 
tial deducers, to higher-order logic programming languages even for single-level 
transformation seems very challenging and has not yet been attempted. Finally, 
it is unclear how much higher-order abstract syntax would help the exponen- 
tial explosion due to multiple encodings in self-application situations since its 
strength is the encoding of variable bindings - not the encoding of arbitrary 
syntax constructors. 

In recent work Q, we proposed a simple language S-graph-n to study meta- 
programming aspects of self-applicable online program specialization from a new 
angle. The primitives of the language provide support for multiple encodings of 
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Programs: 
prog ::= def 

def (DEFINE {fname name\ . . . namCn) tree) 

Trees: 

tree {IF cntr tree tree) \ {CALL {fname arg*)) \ {LKT name exp tree) \ exp 

cntr {EQk? arg arg) \ {CONS? arg name name) \ {M?^ arg^ name name) 

exp {CONS'' exp exp) \ arg 

arg ::= (ATOM" atom) \ (PV name) \ (MV" h name) for any n, h > 0 

Fig. 2. Syntax of S-Graph-n (excerpts) 



(define (rev x a) 

(if (cons? X hd tl) 

(call (rev tl (cons hd a))) 
a)) 

Fig. 3. Tail-recursive list reverse 



programs and the use of metavariables to track unknown values. They were mo- 
tivated by the need for space and time efficient representation and manipulation 
of programs and data in multi-level metaprogramming. Previous work on gener- 
alization focuses only on single-level and has not addressed the unique features 
of metasystem hierarchies. In particular, we are not aware of another line of 
work that has approached foundational and practical issues involved in hierar- 
chies of online specialization systems based on a multi-level metaprogramming 
environment. 

Organization After presenting the subset of S-Graph-n needed for our in- 
vestigation in Section H we develop and formalize the basic metaprogramming 
concepts in Section^ Generalization of configuration values is addressed in Sec- 
tion Jand a well-quasi order for ensuring termination is given in Section ^ In 
Section n we report on the initial design and first experiments with an online 
specializer for S-Graph-n to substantiate the claims. The papers concludes with 
a discussion of related work in Sectionjand future work in Section^ 

2 S-Graph-n 

The choice of the subject language is important for studying foundational prob- 
lems associated with hierarchies of online transformation systems. On the one 
hand the language must be simple enough, so that it can become the object of 
theoretical analysis is and program transformation, and, on the other hand, it 
must be rich enough to serve as a language for writing meta-programs which can 
substantiate theoretical claims by computer experiments. 

In this section we present the language S-Graph-n and its meta-programming 
concepts. The full language is given in here we only need to consider a 
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language fragment. The language seems well-suited for our purposes. Among 
others, a subset of the language was successfully used for clarifying basic concepts 
of supercompilation, e.g. 



2.1 Syntax 

FigureHpresents excerpts of S-Graph-n — a first-order, functional programming 
language restricted to tail-recursion. A program is a list of function definitions 
where each function body is built from a few elements: conditionals IF, local 
bindings LET, function calls CALL, program variables (PV name), and data con- 
structed from the indexed components CONS"', ATOM”, and MV”. The components 
CONS” and ATOM” are the usual constructors for S-expressions, MV” is a construc- 
tor for metavariables (their use will be explained later). The full language ^3 
includes indexed components for each construct of the language {e.g., IF”, LET”, 
etc.). 



2.2 Semantics 

The operational semantics of the language is given elsewhere Here we de- 
scribe it only informally. Evaluation of a S-Graph-n program yields a value — a 
closed {i.e., ground) term in the set described by the grammar shown in Figure^ 
Values are either metavariables, atoms, or CONS-cells indexed by n. As syntactic 
sugar, metavariables (MV” h name) are written as name^. Intuitively, constructs 
indexed by n > 1 represent encoded values from higher levels. 



val G Values 

val-.-.= Xh I (ATOM" otom) | {COTiS"" valval) for any n, h > 0 

Fig. 4. S-Graph-n values (excerpts) 



The test cntr in a conditional may update the environment. We excerpt three 
illustrative contractions from the full language. They test and deconstruct 
values. 

— (EQA? arg^ a%) — tests the equality of two atoms arg^, arg 2 of degree 0. If 
either argument is non-atomic or has a degree other than 0, then the test is 
undefined. 

— (CONS? arg ht) — if the value of arg is a pair (CONS*^ vali ua/ 2 ), then the test 
succeeds and variable h is bound to vali and variable t to vak] otherwise it 
fails. 

— (MV? exp h x) — if the value of exp is a metavariable (MV° vali ua/ 2 ), then the 
test succeeds and variable h is bound to elevation vah and variable x to 
name val 2 ] otherwise it fails. 
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When programming in S-Graph-n, one usually takes 0 as the reference level. 
In the programming examples, components where indices are omitted are at level 
0. FigureHshows a tail-recursive version of list reverse at level 0. As shorthand, 
program variables (PV*' name) are written as name. 

3 Meta-Programming Concepts 

In this section we show how the primitives of the language provide support for 
multiple encodings of programs and then develop the basic meta-programming 
concepts Q for S-Graph-n. We formalize the concepts and illustrate them with 
several examples. 



3.1 Metacoding 

The indexed constructs of S-Graph-n provide a concise and natural representa- 
tion of programs as data. A program component is encoded by simply increasing 
its numerical index. This is formalized by the metacoding function n given below 
(we show only the cases for data constructors). The injectivity of fj. ensures that 
metacoded programs can be uniquely demetacoded. 



^{(ATDM" atom)} = (ATQM"+^ atom) 

^{(CDNS" sfirni sgn.2)} = (CDNS"+^ d-Ugn^}) 

Fig. 5. S-Graph-n metacoding 



Repeated metacoding given by iterated application of ft (denoted fi’' for some 
i > 0) avoids the exponential space explosion characteristic of naive metacoding 
strategies (cf . Example^ . Thereby, the degrading effect such encoding strategies 
have on operations traversing metacode is avoided (e.g., generalization, homeo- 
morphic embedding). 

Example 3. The following example illustrate the representation of encoded data 
in S-Graph-n. 

/^^{(CDNS (ATOM a) (ATOM b))} = (CDNS^ (ATOM^ a) (ATQM^ b)) 

^^{(CDNS (ATOM a) (ATOM b))} = (CDNS^ (ATQM^ a) (ATQM^ b)) 

^^{(CDNS (ATOM a) (ATOM b))} = (CDNS^ (ATOM® a) (ATOM® b)) 

One often needs to embed data with a lower indices as components of constructs 
with higher indices. The degree of an S-Graph-n term is the smallest index oc- 
curring in a term. As motivated in Section^ the degree indicates to which level 
of a hierarchy a component belongs. Intuitively, if a component has degree n. 
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then it has been metacoded n times (though some parts of the component may 
have been metacoded more times). 

Example 4- Consider the following S-Graph-n values. 

(CDNS^ (ATQM^ a) (ATQM^ b)) (1) 

(CDNS^ (ATQM^ a) (ATQM^ b)) (2) 

(CDNS^ (ATQM^ a) (ATDM^ b)) (3) 

The components ^ and Q have degree 1 and Q has degree 2. They have 
been encoded at most once and twice, respectively. 

3.2 Hierarchy of Metacoded Values 

Repeated metacoding of values induces an important property: it creates a hi- 
erarchy of sets of metacoded values. 

^^^{Values} D {Values} D p^{Values} ... 

where for any S, A‘{‘S'} denotes the set obtained by element-wise application of 
pL. Each set of metacoded values is described by the grammar in Figure he., 
pE{Values} = Values[n\). 



vaP G Values[n] 

vaP ::= \ (ATQM"^'^ atom) \ (CDNS’^”''’' vaP vaP) 


for any r, h > 0 


Fig. 6. Sets of metacoded values 





The following property formalizes the characteristic of p,. 

Property 1 (Hierarchical embedding). 

Vn > 0 . Values[n] D Values[n + 1] 

In situations where one has a hierarchy of metasystems as in Figure Q 
Values[n] describes the set of values being manipulated by the program This 
observation plays an important role when we abstract from metacoded values in 
a hierarchy of metasystems. 

Example 5. The values encoded in Examplejbelong to the following value sets. 

^^{(CQNS (ATOM a) (ATOM b))} € Values[l] 

^^{(CDNS (ATOM a) (ATOM b))} G Values[2] 

^®{(CDNS (ATOM a) (ATOM b))} G Values[i] 
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level 0 : 


level n : 


\n 

X 




•h 


level n + h : 


• 




Valuedji+h+l] 


Fig. 7. Positioning of metavariable XJf in an MST Scheme 



3.3 Metavariables and their Domain 

The description of sets of values can be further refined by the use of metavari- 
ables. A metavariable is an abstraction that represents a set of values. A 
metavariable has three attributes which determine its semantics: degree, 
domain, elevation. 

degree{Xf) = n 

domain{Xf) = Values[n + h + 1] 
elevatiorfXf) = h 



Degree n, as we have seen before, indicates the number of times that a metavari- 
able has been metacoded. Domain is the set of values over which a metavariable 
ranges. Elevation h restricts the domain of the metavariable to a particular set of 
metacoded values. For instance, metavariable Xf ranges over Values[3 -I- 1 -h 1] 
(the set of values metacoded five or more times). Although both, degree and 
elevation, are numerical attributes, degree is an absolute characteristics whereas 
elevation is a relative characteristic (it adjusts to the domain relative to degree). 
Thus, elevation is unchanged by metacoding and demetacoding (cf. FigureO- 
The positioning of a metavariable can be illustrated using a metasystem 
transition scheme as in Figure H 

3.4 Configuration Values 

The set of S-Graph-n values is refined to form configuration values where, except 
for metavariables, all values are encoded at least once (m > 1). This reflects the 
situation that a metaprogram pn manipulates pieces of metacode {e.g., program 
fragments) that are encoded at least n-1- 1 times (he., the object level is at least 
one level lower). Intuitively, one can think of configuration values cvaD as a 
description language for characterizing metacoded data patterns occurring in a 
metasystem hierarchy at level n| The importance of correctly abstracting from 

^ Logic variables in queries play a similar role as metavariables in configuration values 
in that both are placeholders that specify unknown entities (note that the latter 
are designed for multi-level metasystem hierarchies and that different metaprograms 
may perform different operations on configuration values, e.g. program specialization, 
inverse computation). 



Generalization in Hierarchies of Online Program Specialization Systems 



187 



cvaV £ Gvalues\n] 

cvaV ::= \ atom) \ (CDNS"”''’” cvaG cvaG) for any r, > 0, m > 1 

Fig. 8. Configuration values 



metacoded values, e.g. when generalizing across several levels of metacode, has 
been explained elsewhere Here we give a formal semantics that justifies 

the generalization and embedding operations defined in the following sections. 

Formally, each configuration value cvar G Cvalues[n] denotes a set 
|cuar]” C Values[n+ 1]. Note that only XJ^ are considered as metavariables 
on level n; metavariables with degree n + m, where m > 1, are treated as en- 
coded constructors. 



I']" : Cvalues[n] p{Values[n + 1]) 

\XJ:T = domamiXj:) 

= {Xn^n 

[(ATQM"+’" atom)Y = {(ATQM"+"* atom)} 

[(cons"’'"’” val\ val2)Y' = {(CDNS"”'"’” cvak cvah) \ vak G lcvakj,vah G Icwofe]} 

Fig. 9. The value sets denoted by configuration values (m > 1) 



Example 6. Consider the configuration value (CONS^ (ATOM^ a) Yq) which, at ref- 
erence level 0, represents a set |(C0NS^ (ATOM^ a) Tq*)]° G Values[l] of metacoded 
values: 

|(CDNS^ (ATQM^ a) yo°)l° = {(CDNS^ (ATQM^ a) (ATQM^ a)), (CDNS^ (ATQM^ a) (ATQM^ b)), . . . , 

(CQNS^ (ATQM^ a) (ATQM^ a)), (CDNS^ (ATQM^ a) (ATQM^ b)), . . . , 

(CDNS^ (ATQM^ a) (ATOM® a)), (CDNS^ (ATQM^ a) (ATOff* b)), . . .} 

Consider the configuration value again, but metacode it once. Now 

(CONS^ (ATOM^ a) Yq^) represents a singleton set at reference level 0. This is justi- 
fied because the metacoded value contains no longer metavariables that belong 
to reference level 0. The metavariable originally contained in the configuration 
value has been ‘pushed down’ one level due to metacoding. 

[(CDNS^ (ATQM^ a) Yq )]° = {(CDNS^ (ATQM^ a) Yq )} 

4 Generalization of Configuration Values 

The explicit identification of the hierarchical position of values given by configu- 
ration values is a key component of the strategy for successful self-application of 
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online specializers given in e.g., This work describes how configuration 

values and metavariables are used to propagate information during specializa- 
tion. 

An equally important component is the termination strategy: avoiding an infi- 
nite sequence of specialization states by folding back to some previously encoun- 
tered specialization state. This may require identifying the information common 
to two specialization states. Since two specialization states must now be de- 
scribed by one, precision may be lost. Thus, one desires the generalization to be 
as specific as possible. 

In our setting, specialization states are described by configuration values 
that represent sets of values. Information belonging to cvatl or cvaU^ is given by 
|cua?|*]"'U|ct;a^]"'. Using configuration values as a description language, the goal 
of generalization is to find a description cvaF^ such that U Icua^]” C 

Icua/^]”. Moreover, the should be as small (precise) as possible. In other 

words, cval^ should be general enough to describe (contain) the sets 
and Icwa^]", but it should be as specific as possible (to minimize the loss of 
information) . 

These concepts can be formalized by extending familiar concepts of most- 
specific generalization, as applied previously to program specialization in e.g., 
to level-index constructors and elevated metavariables. 

4.1 Elevation and Generalization 

Not only the positioning of metavariables by their degree is important in a 
hierarchy of metasystems (cf. Example H, but also the domain specified by 
the elevation index is crucial. Elevation can be seen as (dynamic) typing of 
variables positioned in a metasystem hierarchy. One might imagine enforcing 
well-formedness with a type-system. We have not pursued this option, since 
typed languages are notoriously hard to work with in self-applicable program 
specialization. 

Example 7. Suppose we want to generalize component (ATOM^ a) G Values[2] in 
(CONS^ (ATOM^ a) Fp^) G Values[2] 

such that at reference level 0 the resulting configuration value cvaf describes a 
set |cuaZ°]° C Values[2]. Introducing a metavariable Aq leads to configuration 
value 

KCONS^ X° Foi)f 2 Values[2] 

In other words, the configuration value does not satisfy our condition because it 
admits values such as 

(CONS^ (ATOM^ a) Fp^) ^ Values[2] 

Without the use of elevation, a subset of Values[2] cannot be described by cvaf. 
Adjusting the domain of the metavariable relative to the degree, Xf, gives the 
desired generalization. 



|(C0NS^ X° Fp^)f C Values[2] 
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4.2 Most Specific Domain Index 

The most specific domain index will help us to determine the domain of 
metavariables upon generalization. Clearly, for every cvaf' there exists an i 
such that |cwar]" C domain{Xl^) (one can always take i = 0). However, 
since domains Values[-] form a hierarchy, there exists a maximal k such that 
|cvar]” C domain{XJ}) and |cvar]” % domain{XJ}^-^) . Intuitively, domain{XJ}) 
describes the most specific value domain containing |ct;ar']"'. Therefore, we refer 
to k as the most specific domain index of cvaf' at level n (denoted msdi^ {cvar')) . 



msdt'(-) : Cvalues[n] Number 
msdi^{Xf:) = h 



msdi" = m — 1 

msdi' atom)) = m — 1 

msdi'*((CDNS"'''’” cvak cvah)) — min(m — 1, msdi^ {cval\) , msd’T' {cvah,)) 



Fig. 10. Most specific domain index (m > 1) 



Example 8. Consider the following examples of most specific domain indices. 



ms*'°((CDNS^ (ATQM^ a) A°)) = 1 


(4) 


ms*'°((CDNS® (ATOM® a) A®)) = 2 


(5) 


msdi®((CQNS® (ATOM® a) (ATOff* b))) = 0 


(6) 



4.3 Most Specific Generalization 

We are now in the position to define most specific generalization. First we intro- 
duce elevation-compatible substitution and related operations. 

A binding XJf := aval is a metavariable/configuration value pair. A binding 
is elevation-compatible when h < msdf'{cval). Note that this ensures |cva/[” C 
domain{Xff). A substitution at level n, 0” = := cvaPf, ... := cvaff}, 

is a finite set of bindings such that the metavariables are pairwise distinct. 
A substitution is elevation-compatible when all of its bindings are elevation- 
compatible. An instance of cvalE is a value of the form cvalEO^ where 0" is a 
substitution at level n. 

Definition 1 (renaming, generalization, msg). 

1. A renaming substitution for cvar is a substitution {X^^^ := 

Xff^ '.= YJf^} such that there is a binding for every metavariable occurring 
in cvaf' and are pairwise distinct. 
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2. A generalization of cvafl,cvaff at level n is a triple {evaP^^^, 6^ , Olf) where 
0” and Of are elevation- compatible substitutions, cvaff = cvaf^,,^0f and 
cvaff = cval^^^Of- 

3. A generalization {evaf^^^, df,6f) of evaff and cvalf at level n is most specific 
(msg) if for every generalization {cval'f^^, O’ff, O'ff) of cvatf and evatf, cvaP^^^ 
is an instance of cval'A,„ . 



Definition 2 (Algorithm of msg). For any cvaff,cvalf G Cvalues[n], the 
most specific generalization msg^icvalf, cvaUf) is computed by exhaustively ap- 
plying the rewrite rules of Figure^^to the initial triple 

{Xf,{Xh '■= cvati},{Xh ■.= cvatf}) h — min{msdF{cvalf),msdi3{cval2)) 



where XJf is a variable not occurring in cvaff and cvaff. 

Theorem 1 (most specific generalization). For any cvatf,cvaHf £ 
Cvalues[n], the procedure (Def.^fj is indeed an algorithm, i.e. it terminates and 
the result msg^{cvalf , cvatf) is the most specific generalization at level n. 

Proof. 1. Termination of the algorithm. In every rewrite rule the size of the 
substitutions O, O' or the size of the values in their bindings decreases. Since 
values are well-founded, the rewrite rules can only be applied finitely many 
times. 

2. Soundness of algorithm. We prove by induction over the length of the reduc- 
tion that the algorithm always computes a generalization. 

The initial triple is clearly a generalization. We will show one case; the rest is 
similar. Consider the third reduction rule. We will prove that the right hand 
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side is a generalization of cval^ and cvaS^. Let 9” be { F" := ri, 
We have: 



r{x;: 

r{Xf: 

r{Xf: 



= (C0NS"+'" If" Z^)}9'' = 

= (coNs"+'" If" zf)e"}9" = 

= (CDNS”+'" r;w)}6»" = 

= (CDNS"+'"r;w)}0 =i„ductio„ 



:= te} U 9. 



The second last equality holds because Y , Z are fresh variables. Analogously 
we can prove that: 



:= (C0NS"+'" Z^)}{ := v' , Zp := w'} U 9' = cva^ 

The condition on the rule ensures that the new substitutions are elevation- 
compatible, thus we have proved the case. 

3. Computation of msg. We prove by contradiction that the generalization 
computed by the algorithm is an msg. Assume that the generalization 
01 , 02 ) computed by the algorithm is not an msg, then there ex- 
ists an msg {cvafp^g, 0i, 0^) such that cvatp^g = cvatp^^9'^ where 0" is not a 
renaming substitution. Therefore it must hold that 0”0'j^ = 0i and 0"02 = 02. 
Since 0” is not a renaming substitution it must have one of the two forms: 

{A” := (ATDM"+'" atom)} U 0"" 

{Xp ■= (C0NS"+'" V w)} U 0'" 



for some substitution 0'" . But if 0” has one of these forms also 0i and 02 will 
have that form and either the second or the third rule of Figure^] would 
apply and (cua/^g„, 0i, 02) would not be in normal form. So we have arrived 
at a contradiction and the generalization computed by the algorithm must 
therefore be most specific. 



Property 2 (metacode invariance of msg). For any cvalp,cvaip £ Cvalues[n], 
the most specific generalization at level n is invariant wrt. repeated metacoding 
m > 0. Let 

{cvaC, 0", 02 ) = msg'^{cvaip cvatf) 

for some cvaC, 0” and 91) then there exists cvaC~^"^, 0g and 9^ such that 
(cmr+'",0J,0^) = msg^+"^{fi"^{cvaP},fi"^{cvaq}) 
and iJ."^{cvaC} = cvaC~^^ (modulo renaming of variables). 



Example 9. Following are three examples of most specific generalization at level 
2 and level 3. The first and the last illustrate the invariance property of msg: 

msg^((CDNS^ Xf (ATQM'‘ a)), (CDNS^ Vf (ATQM^ a))) = ((CONS® Zf RI), 

{Zf -.= Xf,Rl := (ATQM^ a)}, 
{Zf := Yf,Rl ~ (ATQM^a)}) 
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ms/((CDNS® Yi y|), (CONS® Zi)) = ((CDNS^ Xg Xg), {X^ ■- Yi}, {X^ ■- Z^}) 

ms/((CDNS'‘ Xi (ATOM® a)), (CONS'* Y® (ATOM* a))) = ((CONS* Z^ Rq), 

{Z^ := Xi,R^ := (ATOM® a)}, 
{Z^ ■.= YtRl ■- (ATOM* a)}) 

5 Embedding of Configuration Values 

The homeomorphic embedding relation known from term algebra Q can be 
used to ensure that unfolding during a specialization process does not proceed 
infinitely. If cvat^ cvat^ then this suggests that cvat^ might arise from cvat^ 
and may lead to some infinitely continuing process and that the transformation 
should be stopped. Variants of this relation are used in termination proofs for 
term rewriting systems and for ensuring termination of partial deduction and 
supercompilation, e.g. in 

In our setting, the embedding relation works on specialization states de- 
scribed by configuration values. 

Definition 3 (Homeomorphic embedding). The homeomorphic embedding 
relation <" C Cvalues[n] x Cvalues[n] is the smallest relation satisfying the rules 
in Figure^^ 

Since there is only a finite number of elevations in a given problem, we strengthen 
the embedding relation for variables on level n (rule VAR) with the condition 
that the elevation indices are identical. Because there may be infinitely many 
variables we have to be conservative and let all encoded variables embed all other 
encoded variables (as long as these have the same index and elevation). The 
rules ATOM and CONS require that the degree of the constructors is identical. 
Rule DIVE-L and DIVE-R detect a configuration value embedded as subterm in 
another larger configuration value; the other rules match components by com- 
ponents. It is not difficult to give an algorithm deciding whether cvatf cvatlf. 

The homeomorphic embedding relation as it is defined is, however, not a 
well quasi-ordering (WQO) on Cvalues[n], since the index and the elevation of 
of elements in Cvalues[n] is not limited, but since we assume that we always 
work with a finite number of elevations and therefore also maximum encoding 
we have the following theorem which is sufficient for ensuring termination for 
MST schemes: 

Theorem 2 (WQO <"). The relation is a well-quasi order on 

Cvalues[n]\{Cvalues[n -I- m] U {Xf^ \ h > m\). 

Proof. Proven by a simple adaption of the proof in the literature since there 
are only finitely many constructors in Gvalues[n]\{Cvalues[n + m] U {Xfli \ h > 

m}B 

^ Without the limitation on the domain Cvalues[n] we could have infinitely many 
constructors, e.g. (ATOM”*’’” a),m > 1. 
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\rn-\-r 


[VAR] 


(ATQM"+’" atom) (ATQM"+’" atom) 


[ATOJVfj 


cvak cva(i cvah cdo^ 


[COJVSj 


(CDNS"+’" cvak cvah) (CDNS"+’" cva( cvat^) 


aval cvak 

cval (CDNS"+"* cvak cvak) 


[DIVE-L] 


cval cvah 

cval (CQNS"+"* cvak cvah) 


[DIVE-R] 


Fig. 12. Homeomorphic embedding on level n 


(m >1, r > 0) 



Property 3 (metacode invariance For any cvaP(, cvat^ G Cvalues[n], relation 
<" is invariant wrt. repeated metacoding , m > 0, fc > 0: 

cvaP( cvaq ^ p"^{cval(} p"^{cvaq} 

In other words, the invariance of wrt. repeated metacoding avoids the 
problems described in Example H 

Example 10. Here are a few examples with the homeomorphic embedding rela- 
tion: 

(ATOM^ a) (CONS^ (ATOM^ a) X(;) 

(ATOM^ a) (CONS^ (ATOM‘S a) X^) 

Yq (CONS^ (ATOM‘S a) Xg) 

(CONS^ ( ATOM‘S a) Xq2) 



6 Self- Applicable Specialization 

The previous sections were concerned with the development of the foundations 
and methods for dealing with multiply encoded data; this one is concerned with a 
practical study in a self-applicable specialize!'. This specialize!' performs constant 
propagation (no propagation of information as in supercompilation). First we 
give an example that introduces the notation, then we illustrate a case of self- 
application. The specializer has two arguments: tree and def where tree is 
the initial expression (metacoded once) and def contains the definitions of the 
program to be specialized. Figure^Jshows how the specialization is setup for 
the reverse program (Figure^ when the first argument is known (the list [1, 2]) 
and the accumulator (a) is unknown (a metavariable on level 0 with elevation 
0 ). 
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Initial call to the (self-applicable) specializer: 

(let tree (call-1 (rev (cons-1 (atom-1 1) 

(cons-1 (atom-1 2) (atom-1 nil))) 
(mv 0 a) ) ) 

(let defs (cons (cons (atom rev) (atom nil)) 

(cons <rev metacoded once> (atom nil))) 

(call (spec-start tree defs))))) 

Result of specialization: 

(cons-1 (atom-1 2) (cons-1 (atom-1 1) (pv-1 a))) 

Fig. 13. Specialization example 



A multi-level example We now turn to a multi-level example. The program we 
consider is again the reverse program, but this time we apply a second version 
of the specializer (self-application) to the specialization of the program, and the 
first list (x) is replaced by a meta-variable at level 0 with elevation 1 and the 
accumulator (a) by a meta- variable at level 1 with elevation 0. This means that 
X is a variable of the outer specializer and a is a variable of the inner specializer. 
This can be illustrated by the following MST scheme: 

level 0 : spec^ x? 

level 1 : speCj | aj 

level 2 : rev( • , • ) 

We now examine some essential steps in the development of the computation. 
The initial call of metasystem hierarchy is shown in Figure^J After some com- 
putation steps this leads to the configuration (1) which the outer specializer will 
memorize such that it can check whether later configurations embed this. We 
assume that a specializer does this for all calls, since unfolding of function calls 
is the only situation that can cause infinite specialization. Since our language 
is tail-recursive all memorized configuration will consists of a call to a function 
from the specializer and we will simply write spec-* to denote some function 
from the specializer. After memorizing the configuration the inner specializer 
(interpreted by the outer) unfolds the call to rev. This leads to a configuration: 

(call (spec-* 

(call-1 (spec-* (if -2 (cons?-2 (mv 1 x) (pv-2 hd) (pv-2 tl)) 

(call-2 (rev (pv-2 tl) 

(cons-2 (pv-2 hd) (mv-1 0 a)))) 

(mv-1 0 a)) . . .)) . . .)) 

in which the inner specializer cannot continue, because to decide the outcome of 
the test it has to know the value of (mv 1 x) and this metavariable belongs to 
the outer specializer. This means that the outer specializer takes over and drives 
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Initial call to the self-applicable speeializer: 

(let tree 

(let-1 tree (call-2 (rev (mv 1 x) (pv-1 0 a))) 

(let-1 defs (cons-1 (cons-1 (atom-1 rev) (atom-1 nil)) 

(cons-1 <rev metacoded twice> (atom-1 nil))) 
(call-1 (spec-start (pv-1 tree) (pv-1 defs))))) 

(let defs <spec metacoded once> 

(call (spec-start tree env defs)))) 

Initial configuration after evaluation (unfolding) of the let- expressions: 

(call (spec-* (call-1 (spec-* (call-2 (rev (mv 1 x) (mv-1 0 a)))) (1) 

. . .) 

. . .)) 

Configuration after some steps of computation (embedding (1 ) ): 

(call 

(spec-* 

(call-1 

(spec-* (call-2 (rev (mv 1 tl) (cons-2 (mv 1 hd) (mv-1 0 a)))) (2) 

. . .)) 

. . .)) 

Generalized configuration (msg of (1) and (2) ): 

(call (spec-* (call-1 (spec-* (call-2 (rev (mv 1 x) (mv 1 z)))) 

. . .) 

. . .)) 

Fig. 14. Specialization example showing embedding and generalization 



the configuration by splitting it into two configurations: one for each branch of 
the conditional. The second of these configurations is (2) shown in Figure 
We have reached a point where configuration (2) embeds (1). 

The fragments represented by ... in configuration (1) and (2) are identical 
and, thus, trivially embed each other. Similarly, the functions spec-* are the 
same in both configurations. So we only have to consider whether the following 
holds: 

(rev (mv 1 x) (mv-1 0 a) ) (rev (mv 1 tl) (cons-2 (mv 1 hd) (mv-1 0 a))) 

Since both trees have the same outer constructor we use the COJVS-rule from 
Figure^] which means that we consider: 

(mv 1 x) (mv 1 tl) and (mv-1 0 a) (cons-2 (mv 1 hd) (mv-1 0 a) ) 

instead. The first of these two clearly holds because of the VAfi-rule in Figure^J 
The second holds because the DTVE-R rule and the VAfi-rule ((mv-1 0 a) < 
(mv-1 0 a)). Configuration (2) embeds (1). 
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Usually, when a late configuration embeds an early configuration during spe- 
cialization this means that there is a risk that specialization will not terminate. 
So therefore we assume that our specialize!' in the example replaces the early 
configuration by the most specific generalization of the two configurations. For 
our example Figure^Jshows the msg of (1) and (2) that is obtained by the 
the method shown in Figure^] 

7 Related Work 

The ideas presented in this paper have been heavily influenced by three con- 
cepts present in Turchin’s work metacoding, metavariables, and metasystem 
transition. Subsequently, these concepts have been formalized and studied 
in different contexts, e.g. | 

Representing and reasoning about object level theories is an important field 
in logic and artificial intelligence (e.g. different encodings have been discussed 
in and has led to the development of logic languages that support declara- 
tive metaprogramming {e.g. the programming language Godel Logic vari- 
ables and unification as provided by their underlying logic system, lack, among 
others, the notion of elevation and the direct support for multiply encoded data. 
In recent work we therefore proposed a simple language S-graph-n to study 
meta-programming aspects of self-applicable online program specialization. It 
will be interesting to study and possibly incorporate some of the notions devel- 
oped here in a logic programming context (e.g. by extending an existing system). 

MetaML, a statically typed multi-level language for hand-writing multi-level 
generating extensions was introduced in Another multi-level programming 
language is Alloy Q, a logic language which provides facilities for deductions 
at different meta-levels and a proof system for interleaving computations at 
different metalevels. A program generator for multi-level specialization (i 1 1 uses 
a functional language extended with multiple-binding times as representation of 
multi-level generating extensions. They allow the design and implementation of 
generative software Q. 

Most specific generalization and the homeomorphic embedding relation are 
known from term algebra B. Variants of this relation are used in termina- 
tion proofs for term rewrite systems and for ensuring local termination of par- 
tial deduction Q. After it was taken up in it has inspired more recent 
work 

8 Conclusion 

Our goal was to clarify foundational issues of generalization and termination in 
hierarchies of programs with multiple encoded data. We examined two popular 
methods, most specific generalization and the homeomorphic embedding rela- 
tion, proved their properties and illustrated their working with simple examples. 
It is clear that several challenging problems lie ahead: the implementation of a 
full system based on the approach advocated in this paper and formalization 
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of other termination and generalization strategies for multi-level hierarchies of 
programs. 

On the theoretical side a thorough comparison of the approach taken in this 
contribution with higher-order logic programming concepts is on the agenda. 
Another challenging question is whether such approaches can be combined and 
used for metaprogramming in general. 

To conclude, we believe the work presented in this paper is a solid basis for 
future work on multi-level program hierarchies and their efficient implementation 
on the computer. 
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Abstract. Well-quasi orders in general, and homeomorphic embedding 
in particular, have gained popularity to ensure online termination of pro- 
gram analysis, specialisation and transformation techniques. It has been 
recently shown that the homeomorphic embedding relation is strictly 
more powerful than a large class of involved well-founded approaches. 

In this paper we provide some additional investigations on the power of 
homeomorphic embedding. We, however, also illustrate that the homeo- 
morphic embedding relation suffers from several inadequacies in contexts 
where logical variables arise. We therefore present new, extended home- 
omorphic embedding relations to remedy this problem. 

Keywords: Termination, Well-quasi orders. Program Analysis, Speciali- 
sation and Transformation, Logic Programming, Functional & Logic Pro- 
gramming. 



1 Introduction 



The problem of ensuring termination arises in many areas of computer science 
and a lot of work has been devoted to proving termination of term rewriting 
systems (e.g. and references therein) or of logic programs (e.g. » If: 



and references therein) . It is also an important issue within all areas of program 
analysis, specialisation and transformation: one usually strives for methods which 
are guaranteed to terminate. One can basically distinguish between two kinds of 
techniques for ensuring termination: 

- offline (or static) techniques, which prove or ensure termination of a program 
or process beforehand without any kind of execution, and 

- online (or dynamic) techniques, which ensure termination of a process during 
its execution. 

Offline approaches have less information at their disposal but do not require 
runtime intervention (which might be impossible) . Which of the two approaches 
is taken depends entirely on the application area. For instance, static termination 
analysis of logic programs falls within the former context, while termina- 

tion of program specialisation, transformation or analysis is often ensured in an 
online manner. 
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This paper is primarily aimed at studying and improving online termination 
techniques. Let us examine the case of partial deduction — an au- 

tomatic technique for specialising logic programs. Henceforth we suppose some 
familiarity with basic notions in logic programming 

Partial deduction based upon the Lloyd and Shepherdson framework gen- 
erates (possibly incomplete) SLDNF-trees for a set A of atoms. The specialised 
program is extracted from these trees by producing one clause (called a resul- 
tant) for every non-failing branch. The resolution steps within the SLDNF-trees 
— often referred to as unfolding steps — are those that have been performed 
beforehand, justifying the hope that the specialised program is more efficient. 

Now, to ensure termination of partial deduction two issues arise One 

is called the local termination problem, corresponding to the fact that each gen- 
erated SLDNF-tree should be finite. The other is called the global termination 
problem, meaning that the set A should contain only a finite number of atoms. 
A similar classification can be done for most other program specialisation tech- 
niques (cf., e.g., K3). 

Below we mainly use local termination to illustrate our concepts. (As shown 
in the atoms in A can be structured into a global tree and methods similar 
to the one for local termination can be used to ensure global termination. See 
also ^3 foi' ^ very general, language independent, framework for termination.) 

However, the discussions and contributions of the present paper are also (im- 
mediately) applicable in the context of analysis, specialisation and transforma- 
tion techniques in general, especially when applied to computational paradigms, 
such as logic programming, constrained logic programming, conditional term 
rewriting, functional programming and functional & logic programming. We also 
believe that our discussions are relevant for other areas, such as infinite model 
checking or theorem proving, where termination has to be insured in non-trivial 
ways. 

One, albeit ad-hoc, way to solve the local termination problem is to simply 
impose an arbitrary depth bound. Such a depth bound is of course not motivated 
by any property, structural or otherwise, of the program or goal under considera- 
tion. In the context of local termination, the depth bound will therefore typically 
lead either to too little or too much unfolding. 

Another approach, often used in partial evaluation of functional programs 
^3, is to (only) expand a tree while it is determinate (i.e. it only has one 
non-failing branch). However, this approach can be very restrictive and in itself 
does not guarantee termination, as there can be infinitely failing determinate 
computations at specialisation time. 



Well-founded Orders Luckily, more refined approaches to ensure local ter- 
mination exist. The first non-ad-hoc methods in logic and 

functional programming were based on well-founded orders, inspired by their 
usefulness in the context of static termination analysis. These techniques ensure 
termination, while at the same time allowing unfolding related to the structural 
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aspect of the program and goal to be specialised, e.g., permitting the consump- 
tion of static input within the atoms of A. 

Definition 1. (wfo) A (strict) partial order >s on a set S is an anti- reflexive, 
anti- symmetric and transitive binary relation on S x S. A sequence of elements 
Si, S2, ■ ■ ■ in S is called admissible wrt >s iff Si > Si+i, for all i > 1. 

We call >s a well-founded order (wfo) iff there are no infinite admissible se- 
quences wrt >s- 

Now, to ensure local termination for instance, one has to find a sensible well- 
founded order on atoms and then only allow SLDNF-trees in which the sequence 
of selected atoms is admissible wrt the well-founded order. If an atom that we 
want to select is not strictly smaller than its ancestors, we either have to select 
another atom or stop unfolding altogether. 

Example 1 . Let P be the reverse program using an accumulator: 

rev{[], Acc, Acc) ^ 

rev([H\T], Acc, Res) ^ rev{T, [H\Acc], Res) 

A simple well-founded order on atoms of the form rev{ti,t2,tfl) might be based 
on comparing the termsize (i.e., the number of function and constant symbols) 
of the first argument. We then define the wfo on atoms by: 

rev{ti,t2,tf) > rew(si , S2, S3) term_size{t2) > term_size{s2) ■ 

Based on that wfo, the goal <— rev{[a, b\T], [], i?) can be unfolded into the goal <— 
rev{[b\T], [a],i?) and further into ^ rev{T, [b,a],R) because the termsize of the 
first argument strictly decreases at each step (even though the overall termsize 
does not decrease). However, ^ rev{T, [5, a],R) cannot be further unfolded into 
<— rev{Tf [Hf b, a],R) because there is no such strict decrease. 

Much more elaborate techniques exist which, e.g., split the ex- 

pressions into classes, use lexicographical ordering on subsequences of the ar- 
guments and even continuously refine the orders during the unfolding process. 
These works also present some further refinements on how to apply wfo’s, es- 
pecially in the context of partial deduction. For instance, instead of requiring a 
decrease wrt every ancestor, one can only request a decrease wrt the covering 
ancestors, i.e. one only compares with the ancestor atoms from which the current 
atom descends (via resolution). (Most of these refinements can also be applied 
to other approaches, notably the one we will present in the next section.) 

However, it has been felt by several researchers that well-founded orders are 
sometimes too rigid or (conceptually) too complex in an online setting. Recently, 
well-quasi orders have therefore gained popularity to ensure online termination 
of program manipulation techniques . In the 

reasons behind this move to well-quasi orders have been formally investigated. 
Notably, [3 shows that a rather simple well-quasi approach — the homeomorphic 
embedding relation — is strictly more powerful than a large class of involved 
well-founded approaches. Nonetheless, despite its power, we will show that the 
homeomorphic embedding is still unsatisfactory when it comes to variables. This 
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paper aims at improving this situation by developing more adequate refinements 
of the homeomorphic embedding relation. 

This paper is structured as follows. In Sections Hand^we provide a gen- 
tle introduction to well-quasi orders and summarise the main results of ^3. 
In Section H we provide some additional investigation, discussing the concept 
of “near-foundedness” In Section we show that, despite its power, the 
homeomorphic embedding is still unsatisfactory when it comes to variables. We 
provide a first solution, which we then improve in Section^ notably to be able 
to cope with infinite alphabets. 

2 Well-quasi orders and homeomorphic embedding 

Formally, well-quasi orders can be defined as follows. 

Definition 2. (quasi order) A quasi order >s on a set S is a reflexive and 
transitive binary relation on S x S. 

Henceforth, we will use symbols like <, > (possibly annotated by some sub- 
script) to refer to strict partial orders and <, > to refer to quasi orders and 
binary relations. We will use either “directionality” as is convenient in the con- 
text. We also define an expression to be either a term (built-up from variables 
and function symbols of arity > 0) or an atom (a predicate symbol applied to a, 
possibly empty, sequence of terms), and then treat predicate symbols as function 
symbols, but suppose that no confusion between function and predicate symbols 
can arise (i.e., predicate and function symbols are distinct). 

Definition 3. (wbr,wqo) Let <g be a binary relation on S x S. A sequence 
of elements Si, S 2 , ■ ■ ■ in S is called admissible wrt <5 iff there are no i < j such 
that Si <s Sj. We say that <g is a well-binary relation (wbr) on S iff there are 
no infinite admissible sequences wrt <5. If <5 is a quasi order on S then we 
also say that <s is a well-quasi order (wqo) on S. 

Observe that, in contrast to wfo’s, non-comparable elements are allowed 
within admissible sequences. An admissible sequence is sometimes called bad 
while a non-admissible one is called good. A well-binary relation is then such 
that all infinite sequences are good. There are several other equivalent defini- 
tions of well-binary relations and well-quasi orders. Higman used an alternate 

definition of well-quasi orders in terms of the “finite basis property” (or “finite 
generating set” in E|). Both definitions are equivalent by Theorem 2.1 in Q. A 
different (but also equivalent) definition of a wqo is(e.g., ^3^9)- ^ quasi-order 
<y is a wqo iff for all quasi-orders which contain <y (i.e. v<yv' ^ v^yv') 
the corresponding strict partial order -<y is a wfo. This property has been ex- 
ploited in the context of static termination analysis to dynamically construct 
well-founded orders from well-quasi ones and led to the initial use of wqo’s in 
the offline setting The use of well-quasi orders in an online setting has 

only emerged recently (it is mentioned, e.g., in | but also ^]) and provides 
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the first formal comparison! Furthermore, in the online setting, transitivity of 
a wqo is not really interesting (because one does not have to generate wfo’s) and 
one can therefore drop this requirement, leading to the use of wbr’s. Later on in 
Sections HandH we will actually develop wbr’s which are not wqo’s. 

An interesting wqo is the homeomorphic embedding relation <, which derives 
from results by Higman ^Sand Kruskal It has been used in the context of 
term rewriting systems irT^^Q, and adapted for use in supercompilation in 
. Its usefulness as a stop criterion for partial evaluation is also discussed and 






advocated in 
summarised in 



r^) 



and 



(also 



I^Some complexity results can be found in 

. > 

The following is the definition from EH, which adapts the pure homeomor- 
phic embedding from Q by adding a rudimentary treatment of variables. 



Definition 4. The (pure) homeomorphic embedding relation < on expressions 
is inductively defined as follows (i.e. < is the least relation satisfying the rules): 

1. X <Y for all variables X, Y 

2. s < f{ti , . . ,,tn) if s <ti for some i 

3. f{si, ...,Sn)< fih, ...fin) if^i G {1, . . .,n} : Si < U. 



The second rule is sometimes called the diving rule, and the third rule is 
sometimes called the coupling rule (notice that n is allowed to be 0). When s<\t 
we also say that s is embedded in t or t is embedding s. By s <1 f we denote that 
s < f and t ^s. 

The intuition behind the above definition is that A<B iff A can be obtained 
from B by “striking out” certain parts, or said another way, the structure of A 
reappears within B. Indeed, just applying the coupling rule 3 we get syntactic 
identity for ground expressions, rule 1 just confounds all variables, and the diving 
rule 2 allows to ignore a part (namely f{ti , . . . , ti+i , . . . , f„)) of the right- 

hand term. 



Example 2. Wehavep(a)<p(/(a)) and indeed p(a) can be obtained from p(/(a)) 
by “striking out” the /; see Fig.J Observe that the “striking out” corresponds to 
the application of the diving rule 2 and that we even have p{a) <\p{f{a)). We also 
have, e.g., that: A<A, p{X)<ip{f{Y)), p{X, X)<p{X, Y) andp(A, Y)<p{X, X). 



Proposition 1. < is a wqo on the set of expressions over a finite alphabet. 

To ensure, e.g., local termination of partial deduction, we have to ensure that 
the constructed SLDNF-trees are such that the selected atoms do not embed any 
of their ancestors (when using a well-founded order as in Example^ we had to 
require a strict decrease at every step). If an atom that we want to select embeds 
one of its ancestors, we either have to select another atom or stop unfolding 
altogether. For example, based on <, the goal <— rev{[a, b\T], [], i?) of Example^ 

^ There has been some comparison between wfo’s and wqo’s in the offline setting, e.g., 
in it is argued that (for “simply terminating” rewrite systems) approaches based 
upon quasi-orders are less interesting than ones based upon a partial orders. 
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Fig. 1. Illustrating Example^ 



can be unfolded into ^ rev{[b\T],[a],R) and further into <— rev{T,[b,a], R) 
as rev{[a,b\T],[], R) ^ren([6|T], [a], i?), rev{\a,b\T],[\,R) -^reviT^lb^a], R) and 
ren([6|r], [a], i?) ^ren(r, [6, a], i?). However, <— rev{T, [b, a],R) cannot be further 
unfolded into ^ rev{T' ,[H' ,b, a], R) as rev{T,[b, a], R) < rev{T' ,[H' ,b, a], R). 
Observe that, in contrast to Example B we did not have to choose how to 
measure which arguments. We further elaborate on the inherent flexibility of < 
in the next section. 

The homeomorphic embedding relation is also useful for handling structures 
other than expressions. It has, e.g., been successfully applied in to 

detect (potentially) non-terminating sequences of characteristic trees. Also, < 
seems to have the desired property that very often only “real” loops are detected 
and that they are detected at the earliest possible moment (see B3)’ 

3 Comparing wbr’s and wfo’s 

In this section we summarise the main results of 

It follows from Definitions J and Hthat if <y is a wqo then <y (defined by 
vi <u V2 iff V\ <u V2 A vi V2) is a wfo, but not vice versa. The following 
shows how to obtain a wbr from a wfo. 

Lemma 1. Let <y be a well-founded order on V . Then -<y , defined by Vi :<v V2 
iff vi V V2, is a wbr on V . Furthermore, <y and :<y have the same set of 
admissible sequences. 

This means that, in an online setting, the approach based upon wbr’s is in 
theory at least as powerful as the one based upon wfo’s. Further below we will 
actually show that wbr’s are strictly more powerful. 

Observe that is not necessarily a wqo: transitivity is not ensured as 
ti t2 and t2 'f- ts do not imply ti t^. Let, e.g., s < t denote that s is 
strictly more general than t. Then < is a wfo but p{X, X, a) p{X, Z, b) 
and p{X, Z, b) p{X, Y, a) even though p{X, X, a) > p{X, Y, a). 

Let us now examine the power of one particular wqo, the earlier defined <. 
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The homeomorphic embedding < relation is very flexible. It will for example, 
when applied to the sequence of covering ancestors, permit the full unfolding of 
most terminating Datalog programs, the quicksort or even the mergesort pro- 
gram when the list to be sorted is known (the latter poses problems to some static 
termination analysis methods for some experiments see Also, the 

produce- consume example from requires rather involved techniques (consid- 
ering the context) to be solved by wfo’s. Again, this particular example poses 
no problem to < (cf. 

The homeomorphic embedding < is also very powerful in the context of 
metaprogramming. Notably, it has the ability to “penetrate” layers of (non- 
ground) meta-encodings (cf. and ^3 for further discussions on that matter; 
cf. also the appendix of for some computer experiments) . For instance, < will 
admit the following sequences (where, among others, Example^is progressively 
wrapped into “vanilla” metainterpreters counting resolution steps and keeping 
track of the selected predicates respectively): 



Sequence 

rev{[a,b\T], [], A) rev{[b\T], [a], A) 
solve{rev{[a, b\T], [], A), 0) solve(rev{[b\T], [a], A), s(0)) 
solve'{solve{rev{[a, b\T], [], R), 0), []) solve'{solve{rev{[b\T], [a], R), s(0)), [rev]) 
path(a, &, []) -^ path(b, a, [a]) 

solve' {solve{path{a,b, []),0), []) solve'{solve{path{b, a, [a]),s(0)), [rev]) 

Again, this is very difficult for wfo’s and requires refined and involved techniques 
(of which to our knowledge no implementation in the online setting exists) . For 
example, to admit the third sequence we have to measure something like the 
“termsize of the first argument of the first argument of the first argument.” For 
the fifth sequence this gets even more difficult. 

We have intuitively demonstrated the usefulness of < and that it is often 
more flexible than wfo’s. But can we prove some “hard” results? It turns out 
that we can and establishes that — in the online setting — < is strictly 
more generous than a large class of refined wfo’s containing the following: 

Definition 5. A well-founded order -< on expressions is said to be monotonic 
iff the following rules hold: 

1. X )f- Y for all variables X, Y , 

2. s)f f(ti , . . . , tn) whenever f is a function symbol and s )/- ti for some i and 

3. f{si,...,Sn) f f{ti,...,tri) whenever yi £ {1, . . . ,n} : Si ^ ff. 

Observe that point 2 need not hold for predicate symbols and that point 3 
implies that c c for all constant and proposition symbols c. There is also a 
subtle difference between monotonic wfo’s as of Definition J and wfo’s which 
possess the replacement property (such orders are called rewrite orders in 
and monotonic in Q). More on that below. 

^9 shows that most of the wfo’s used in online practice are actually mono- 
tonic: 
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- Definitions 3.4 of Q, 3.2 of and 2.14 of all sum up the number 
of function symbols (i.e. termsize) of a subset of the argument positions of 
atoms. The algorithms only differ in the way of choosing the positions to 
measure. The early algorithms measure the input positions, while the later 
ones dynamically refine the argument positions to be measured. All these 
wfo’s are monotonic. 

- Definitions 3.2 of as well as 8.2.2 of use the lexicographical order 
on the termsizes of some selected argument positions. These wfo’s are also 
monotonic, as proven in 

The only non-monotonic wfo in that collection of articles is the one defined 
specifically for metainterpreters in Definition 3.4 of | (also in Section 8.6 of 
^3) which uses selector functions to focus on subterms to be measured. 

We now adapt the class of simplification orderings from term rewriting sys- 
tems. The power of this class of wfo’s is also subsumed by <. 

Definition 6. A simplification ordering is a wfo -< on expressions which satis- 
fies 

1. s f{ti, ...,s,...,tn) -< (replacement property), 

2. t f{ti , . . . . . . ,tn) (subterm property) and 

3. s ^ t ^ sa tj for all variable only substitutions a and 7 (invariance under 
variable replacement). 

The third rule of the above definition is new wrt term-rewriting systems and 
implies that all variables must be treated like a unique new constant. It turns 
out that a lot of powerful wfo’s are simplification orderings recursive path 

ordering, Knuth-Bendix ordering or lexicographic path ordering, to name just a 
few. However, not all monotonic wfo’s are simplification orderings and there are 
wfo’s which are simplification orderings but are not monotonic. 

Proposition 2. Let -< be a wfo on expressions. Then any admissible sequence 
wrt -< is also an admissible sequence wrt < if ^ is a) monotonic or if it is b) a 
simplification ordering. 

This means that the admissible sequences wrt < are a superset of the union 
of all admissible sequences wrt simplification orderings and monotonic wfo’s. In 
other words, no matter how much refinement we put into an approach based 
upon monotonic wfo’s or upon simplification orderings we can only expect to 
approach < in the limit. But by a simple example we can even dispel that hope. 



Example 3. Take the sequence 5 = f{a), f{b),b,a. This sequence is admissible 
wrt < as /(a) ^/(6), /(a) fib, f{a) fia, fib) fib, fib) fia and a fib. However, 
there is no monotonic wfo -< which admits this sequence. More precisely, to 
admit 8 we must have /(a) f{b) as well asb>- a, i.e. af- b. But this violates 
rule 3 of Definition H and ^ cannot be monotonic. This also violates rule 1 of 
DefinitionHand ^ cannot be a simplification ordering. 
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These new results relating < to monotonic wfo’s shed light on <’s usefulness 
in the context of ensuring online termination. 

But of course the admissible sequences wrt < are not a superset of the union 
of all admissible sequences wrt any wfo|For instance the list-length norm || .\\uen 
is not monotonic, and indeed we have for t\ = [1, 2, 3] and t 2 = [[1, 2, 3], 4] that 
1 1 till /Jen = 3 > ||t 2 ||//en = 2 although t\ < So there are sequences admissible 
wrt list-length but not wrt <. The reason is that |j.||/jen in particular and non- 
monotonic wfo’s in general can completely ignore certain parts of the term, while 
< will always inspect that part. E.g., if we have s and ignores 

the subterm t then it will also be true that s /(. . . s . . .) while s </(... s . . .)| 
i.e. the sequence s, /(. . . s . . .) is admissible wrt but not wrt <. 

Of course, for any wfo (monotonic or not) one can devise a wbr (cf. LemmaJ 
which has the same admissible sequences. Still there are some feats that are 
easily attained, even by using <, but which cannot be achieved by a wfo ap- 
proach (monotonic or not). Take the sequences Si = p([], [a]),p([a], []) and 
S 2 = p([a], []),p([], [a]). Both of these sequences are admissible wrt <\. This illus- 
trates the flexibility of using well-quasi orders compared to well-founded ones in 
an online setting, as there exists no wfo (monotonic or not) which will admit both 
these sequences. It, however, also illustrates why, when using a wqo in that way, 
one has to compare with every predecessor state of a process. Otherwise one can 
get infinite derivations of the form p([a], []) — > p([], [a]) — » p([a], []) — . .|ln 
other words, for wqo’s, the composition si, . . . , Sm of two admissible sequences 
Si, . . . , s„ and s„, s„+i , . . Sm is not necessarily admissible. This is in contrast 
to wfo’s. 

Finally, one could argue that it is possible to extend the power of the wfo- 
approach by defining wfo’s over histories (i.e., sequences) instead of the individ- 
ual elements. This is, however, not the way that wfo’s are used in practice and one 
is faced with the difficulty of defining a sensible order on sequences. Of course, one 
could always use a wqo ^ to define such an order: si, . . . , s„ > Si, . . . , s„, s„+i 
iff Vz £ {1, . . . , n} : Si s„+i. One would thus get an approach with exactly the 
same power and complexity as the wqo-approach. 



4 Nearly-Foundedness and Over-Eagerness 

In as well as in Section 8.2.4 of ^3, a technique for wfo’s is formally in- 
troduced, based upon nearly-foundedness. As already mentioned earlier, some 

^ Otherwise < could not be a wqo, as all finite sequences without repetitions are 
admissible wrt some wfo (map last element to 1, second last element to 2, . . . ). 

® Observe that if / is a predicate symbols then /(. . . s . . .) is not a valid expression, 
which enabled us to ignore arguments to predicates. 

When using a wfo one has to compare only to the closest predecessor because of 
the transitivity of the order and the strict decrease enforced at each step. However, 
wfo’s are usually extended to incorporate variant checking and then require inspect- 
ing every predecessor anyway (though only when there is no strict weight decrease. 
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of the techniques in start out with a very coarse wfo <i which is 

then continuously refined, enabling a clever choice of weights for predicates and 
their respective arguments (deciding beforehand upon appropriate weights can 
be extremely difficult or impossible; see examples in Section H. For example 
we might have that <i is based upon measuring the sum of the termsize of all 
arguments and the process of refining consists in dropping one or more argu- 
ments. For example, suppose that we have some sequence Si, S2, . . . , Si which is 
admissible wrt the initial wfo <i but where s^+i yli Si with s^+i = p(a, s(s( 6 ))) 
and Si = p{s{a),b). In that case we can move to a refinement <2 of <1 in 
which only the termsize of the first argument is measured, enabling the move 
from Si to Si+i (as Si+i <2 Si). This, however, does not guarantee that the 
whole sequence Si, S2, . . . , Si, Si+i is admissible wrt <2. E.g., for the sequence 
p{s{a), s{s{s{c)))),p{s{a),b),p{a, s{s{b))) with i = 2 we have S2 ^2 Si even 
though S2 <1 Si. 

To solve this problem, the earlier algorithms verified that a refinement keeps 
the whole sequence admissible (otherwise it was disallowed). The problem with 
this approach is that re-checking the entire sequence can be expensive. 
therefore advocates another solution: not re-checking the entire sequence on the 
grounds that it does not threaten termination (provided that the refinements 
themselves are well-founded) . This leads to sequences si , S2 , . . . which are not 
well-founded but nearly-founded meaning that Si Sj only for a finite 

number of pairs (z, j) with i > j. 

In summary, the motivation for nearly-foundedness lies in speeding up the 
construction of admissible sequences (not re-scanning the initial sequence upon 
refinement). As a side-effect, this approach will admit more sequences and, e.g., 
solve some of our earlier examples (as a suitably large depth bound would as 
well). However, from a theoretical point of view, we argue below that nearly- 
foundedness is difficult to justify and somewhat unsatisfactory. 

First, we call a technique over-eager if it admits sequences which are not 
admitted by the variant test (i.e., it admits sequences containing variants). We 
call such a technique strictly over- eager if it admits sequences which contain 
more than 1 occurrence of the same syntactic term. 

A depth bound based technique is strictly over-eager, which is obviously a 
very undesir^le property indicating some ad-hoc behaviour. The same can (al- 
most alwaysjalso be said for over-eagerness. For instance, in the context of par- 
tial deduction or unfold/fold program transformation, over-eager unfolding will 
“hide” possibilities for perfect folding (namely the variants) and also lead to too 
large specialised programs. An approach based upon homeomorphic embedding 
is not over-eager nor is any other wfo/wqo based approach which does not dis- 
tinguish between variants. However, as we show below, using nearly-foundedness 
leads to strict over-eagerness. 

Let us first describe the way nearly-founded sequences are constructed in 
First, we define a well-founded order acting on a set W of well- 
founded orders on expressions. To construct admissible sequences of expressions 



® See discussion in Sectionjconcerning the variant test on covering ancestors. 
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wrt ^vv we start by using one wfo <iG W until the sequence can no longer be 
extended. Once this is the case we can use another wfo <26 W which admits 
the offending step, provided that <2-<w<i- It is not required that the whole 
initial sequence is admissible wrt <2, just the last step (not admitted by <i). 
We can now continue expanding the sequence until we again reach an offending 
step, where we can then try to refine <2 into some <3 with <3^w<2, and so 
on, until no further expansion is possible. 

Example 4 - Take the following program. 
p{[a,a\T],[a\Y]) ^ p{T,Y) 
p([ 5 , 6 , 5 |r],y)^p(T,[ 6 , 5 |Y]) 
p(T,[ 5 , 6 |F])^p([a,a,&, b,b\T],[a\Y]) 

Let us now define the following well-founded orders, where ||t||(s denotes the 
termsize of t. 

<{1.2}: p(si, S2) < p{tl,t2) iff \\si\\ts + ||S 2 ||ts < ||il||ts + ||i2||ts 
<{1>: p(si,S2) <p{ti,t2) iff ||si||ts < \\ti\\ts 
<{ 2 >: p{si, S2) < p{ti, t2) iff \\s2\\ts < I|t 2 ||ts 
We also define the wfo on the above well-founded orders: <{i}<w<{i,2} and 
<{2}<w<{i,2}- In other words we can refine <{1,2} into <{1} or <{2}, which in 
turn cannot be further refined. 

We can now construct the following admissible sequence in which two terms 
{p{[a, a, b, b, b], [a]) and p{[b, 5 , 6], [])) appear twice: 

p{[a,a, b, b,b], [a]) 

i <{1,2} 

P{[b, b,b], []) 

i <{1,2} 

P{{],{b,b]) 

i <{2} (refinement) 
p{[a,a,b, b,b], [a]) 

i <{2} 

P{[b, b,b], []) 

Example H tl^ns proves that nearly- foundedness may result in strict over- 
eagerness. (As a side-effect, the example also shows that the nearly- foundedness 
approach cannot be mapped to a wfo-approach, however involved it might be.) 
Although it is unclear how often such situations will actually arise in practice, 
we believe that the strict over-eagerness is just one of the (mathematically) 
unsatisfactory aspects of nearly- foundedness. 

5 A more refined treatment of variables 

While < has a lot of desirable properties it still suffers from some drawbacks. 
Indeed, as can be observed in Example^ the homeomorphic embedding relation 
< as defined in DefinitionHis rather crude wrt variables. In fact, all variables 
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are treated as if they were the same variable, a practice which is clearly un- 
desirable in a logic programming context. Intuitively, in the above example, 
p{X,Y) <p{X,X) can be justified (see, however. Definition J below), while 
p{X, X) <p{X, Y) is not. Indeed p{X, X) can be seen as standing for something 
like and{eq{X,Y),p{X,Y)), which embeds p{X,Y), but the reverse does not 
hold. 

Secondly, < behaves in quite unexpected ways in the context of general- 
isation, posing some subtle problems wrt the termination of a generalisation 
process. 

Example 5. Take for instance the following generalisation algorithm, which ap- 
pears (in disguise) in a lot of partial deduction algorithms (e.g., (In 

that context A is the set of atoms for which SLDNF-trees have already been 
constructed while B are the atoms in the leaves of these trees. The goal of the 
algorithm is then to extend A such that all leaf atoms are covered.) 

Input: two finite sets A,B of atoms 

Output: a finite set A' ^ A s.t. every atom in B is an instance of an atom in A' 
Initialisation: A' := A, B' := B 
while B' ^ ^ do 

remove an element B from B' 
if B is not an instance of an element in A' then 
if 3A € A' such that AAB then 
add msg{A, B) to B' 
else add B to A' 



The basic idea of the algorithm is to use < to keep the set Al finite in the limit. 
However, although the above algorithm will indeed keep Al finite, it still does not 
terminate. Take for example A = {p{X^ X)} and B = ^)}- We will remove 

B = p{X, Y) from B' = {p{X^ T)} in the first iteration of the algorithm and we 
have that B is not an instance of p{X^ X) and also that p{X^ X) < p(X, Y). We 
therefore calculate the msg{{p{X,X),p{X,Y)}) = p{X,Y) and we have a loop 
(we get B' = {p{X,Y)}). 



To remedy these problems, 
morphic embedding as follows: 



iill C4I Mr 



introduced the so called strict homeo- 



Definition 7. Let A, B be expressions. Then B (strictly homeomorphicalljd em- 
beds A, written as A B, iff A< B and A is not a strict instance of 



Example 6. We now still have that p{X, Y) <+ p{X, X) but not p{X, X) <+ 
p{X, F). Note that still X <+ F and X <+ X. 



H is a strict instance of B iff there exists a substitution 7 such that A = Bj and 
there exists no substitution cr such that B = Aa. 
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A small experiment, specialising a query rotate(X,X) (using the ecce sys- 
tem ^3 with < and respectively on conjunctions for global control; the 
rotate program, rotating a binary tree, can be found in ^3) demonstrates the 
interest of <: when using <+ we obtain an overall speedup of 2.5 compared to 
“only” 2.0 using <. 

Notice that, if we replace < of Example^by we no longer have a problem 
with termination (see^^^J for a termination proof of an Algorithm containing 
the one of Example 

The following is proven in 

Theorem 1. The relation <“'■ is a wbr on the set of expressions over a finite 
alphabet. 

Observe that is not a wqo as it is not transitive: we have for exam- 
ple p{X, X, Y, Y) <+ p{X, Z, Z, X) as well as p{X, Z, Z, X) <+ p{X, X, Y, Z) 
but p{X, X,Y,Y) A, Y, Z). One might still feel dissatisfied with that 

definition for another reason. Indeed, although going from p{X) to the in- 
stance p{f{X)) (and on to p{f{f{X))),...) looks very dangerous, a transi- 
tion from p{X, Y) to p(A, X) is often not dangerous, especially in a data- 
base setting. Take for example a simple Datalog program just consisting of the 
clause p{a,b) ^ p{X,X). Obviously P will terminate (i.e., fail finitely) for all 
queries but will not allow the selection of p{X, X) in the following derivation 
^ p{X, Y) ^ p{X, A) fail of P U p(A, Y)}, hence preventing full 

unfolding and the detection of finite failure. On the practical side this means 
that neither <+ nor < will allow full unfolding of all terminating queries to 
Datalog programs (although they will allow full unfolding of terminating ground 
queries to range-restricted Datalog programs). To remedy this, we can develop 
the following refinement of 

Definition 8. We define s <var t iff s <\t or s is a variant of t. 

Wehavep(A)<„,,p(/(A)) andp(A, Y)<„,,p(2-, A) but p(A, A) ^„,,p(A,Y) 
andp(A,Y) ^„,,p(A,A). 

It is obvious that <var is strictly more powerful than (if t is strictly more 
general than s, then it is not a variant of s and it is also not possible to have 
s <\ t). It thus also solves the generalisation problems of < (i.e., if we produce a 
strict generalisation g of some expression t, then t ^varO)- In addition <yar has 
the following property: if we have a query Q to a Datalog program which left- 
terminates then the LD-tree for <— Q is admissible in the sense that, for every 
selected literal L, we have L j^yar^ for all covering ancestors A of L. Indeed, 
whenever we have that L<A for two Datalog atoms L and A then we must also 
have A<L (as the diving rule of < cannot be applied). Thus, for Datalog, <yar 
is equivalent to the variant test. Now, if a derivation from ^ A leads to a goal 
<— Pi, . . . , where Pi is a variant of a covering ancestor A, then it is possible 
to repeat this left-to-right derivation again and again and we have a real loop. 

Theorem 2. The relation <yar is a wqo on the set of expression over a finite 
alphabet. 
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The proof can be found in Observe that <var is, like < and not a 
wqo over an infinite alphabet. More on that in Section ^ 



Discussion 

Observe that the variant test is (surprisingly) not complete for Datalog in gen- 
eral (under arbitrary computation rules). Take the program just consisting of 
p{b,a) ^ p{X, Z),p{Z,Y). Then the query ^ p{X,Y) is finitely failed as the 
following derivation shows: 

p{X,Y) ^ p{X\Z') ,p{Z\ Y') ^ p{X\ Z"),p{Z", Y"), p{a,Y') ^fatl- 
However, at the second step (no matter what we do) we have to select a variant 
of the covering ancestor p{X, Y) and the variant test will prevent full unfolding. 

An alternate approach to DefinitionsnandH — at least for the aspect of treat- 
ing variables in a more refined way — might be based on numbering variables 
using some mapping #(.) and then stipulating that X Y iff #(A^) < #(T). 
For instance in a de Bruijn numbering of the variables is proposed. Such an 
approach, however, has a somewhat ad hoc flavour to it. Take for instance the 
terms p{X,Y,X) and p{X,Y,Y). Neither term is an instance of the other and 
we thus have p{X, Y, X) <+p(A, Y, Y) and p{X, Y, Y) <+p(A, Y, X). Depending 
on the particular numbering we will either have that p{X, Y, X) ^^p(A, Y) Y) 
or that p{X,Y,Y) ^"^p{X,Y, X), while there is no a pp arent reason why one 
expression should be considered smaller than the other| 

6 Extended homeomorphic embedding 

Although <+ from Definition J has a more refined treatment of variables and 
has a much better behaviour wrt generalisation than < of Definition^ it is still 
somewhat unsatisfactory. 

One point is the restriction to a finite alphabet. Indeed, for a lot of practical 
logic programs, using, e.g., arithmetic built-ins or even = ../2, a finite alphabet 
is no longer sufficient. Luckily, the fully general definition of homeomorphic em- 
bedding as in^B^I remedies this aspect. It even allows function symbols with 
variable arity|We will show below how this definition can be adapted to a logic 
programming context. 

However, there is another unsatisfactory aspect of (and <„ar)- Indeed, it 
will ensure that p{X, X) ^+p(A, Y) while p{X, X) < p{X, Y) but we still have 
that, e.g., f{a,p{X,X)) <+ f{f{a),p{X,Y)). In other words, the more refined 
treatment of variables is only performed at the top, but not recursively within 
the structure of the expressions. For instance, this means that will handle 
rotate(X,X) much better than < but this improvement will often vanish when 
we add a layer of metainterpretation. 

^ also proposes to consider all possible numberings (but leading to n\ complexity, 
where n is the number of variables in the terms to be compared). It is unclear how 
such a relation compares to and <var- 
® Which can also be seen as associative operators. 
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The following, new and more refined embedding relation remedies this some- 
what ad hoc aspect of 

Definition 9. Given a wbr on the function symbols and a wbr on se- 
quences of expressions, we define the extended homeomorphic embedding on 
expressions by the following rules: 

1. X <* Y if X and Y are variables 

2. s <* f{ti, . . . ,tn) if s <* ti for some i 

3. /(si , . . . , Sm) <* g{ti ,...,tn) if f diF g and 31 < ii < . . . < im < n such 

that Vj € { 1 , . . . , . Sj ^ t^^ and (si , . . . , s^m) (^i ; • ■ • ; In) 

Observe that for rule 3 both n and m are allowed to be 0, but we must 
have m < n. In contrast to Definitionjfor <, the left- and right-hand terms in 
rule 3 do not have to be of the same arity. The above rule therefore allows to 
ignore n — m arguments form the right-hand term (by selecting the m indices 

?!<...< irn) • 

Furthermore, the left- and right-hand terms in rule 3 do not have to use the 
same function symbol: the function symbols are therefore compared using the 
wbr -<p. If we have a finite alphabet, then equality is a wqo on the function 
symbols (one can thus obtain the pure homeomorphic embedding as a special 
case). In the context of, e.g., program specialisation or analysis, we know that 
the function symbols occurring within the program (text) and call to be analysed 
are of finite number. One might call these symbols static and all others dynamic. 
A wqo can the be obtained by defining f ^ g if either / and g are dynamic or 
if f = g. For particular types of symbols a natural wqo or wbr exists (e.g., for 
numbers) which can be used instead. Also, for associative symbols (such as A) 
one can represent Ci A . . . A c„ by A (ci , . . . , c„) and then use equality up to arities 
(e.g., A/2 = A/3) for 

Example 7. If we take to be equality up to arities and ignore A5 (i.e., define 
A5 to be always true) we get all the embeddings of <, e.g., p{a) <* p{f{a)). 
But we also get p{a) <* p{b, f{a),c) (while p{a) < p{b, f{a),c) does not hold), 
A{p{a),q{b)) <* A{s,p{f{a)),r,q{b)) and A{a,b,c) <* A{a,b,c,d). One can see 
that <* provides a convenient way to handle associative operators such as the 
conjunction A. (Such a treatment of A has been used in to ensure 

termination of conjunctive partial deduction. It might prove equally beneficial 
for constrained partial deduction Indeed, in the context of < one cannot use 
A with all possible arities and one has to use, e.g., a binary representation. But 
then whether A{a,b,c) is embedded in A{a,b,c,d) (which, given associativity, 
it is) depends on the particular representation: A (a, A (5, c)) < A (a, A (A (5, c),d)) 
but A(a, A(5, c)) ^ A (A(a, 6), A(c, d)). 

In the above definition we can now instantiate A 5 such that it performs a 
more refined treatment of variables, as discussed in Section H For example we 
can define: (si, . . . , Sm) :fs {ti, ■ ■ ■ , In) iff (ti, • ■ • , tn) is not strictly more general 
than (si, . . . , Sm). (Observe that this means that if m n then <s will hold.) 
This relation is a wbr (by Lemma H as the strictly more general relation is 
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a wfo ^3). Then, in contrast to and <var, this refinement will be applied 
recursively within <* . For example we now not only have p{X, X) ^*p{X, Y) but 
also f{a,p{X,X)) ^*/(/(a),p(X, F)) while f{a,p{X,X)) <+ /(/(a),p(X, F)). 

The reason why a recursive use of, e.g., the “not strict instance” test was not 
incorporated in which use was that the authors were not sure that 

this would remain a wbr (no proof was found yet). In fact, recursively applying 
the “not strict instance” looks very dangerous. Take, e.g., the following two atoms 
^0 = p{X, X) and Ai = q{p{X, Y),p{Y, J*f)). In fact, although we do 

not have Aq <* Ai (when, e.g., considering both q and p as static function sym- 
bols) and one wonders whether it might be possible to create an infinite sequence 
of atoms by, e.g., producing A2 = p{q{p{X, Y),p(Y, Z)),q{p{Z, V),p{V, X))).We 
indeed have Ai ^*A2, but luckily Aq <* A2 and <* satisfies the wqo require- 
ment of Definition^ But can we construct some sequence for which <* does not 
conform to Definition ^ 

The following TheoremHshows that such a sequence cannot be constructed. 
However, if we slightly strengthen point 3 of Definition Q by requiring that 
(si, . . . , Sm) is not a strict instance of the selected subsequence {ti ^, . . . , 
we actually no longer have a wqo, as the following sequence of expression shows: 
Ho = f{p{X,X)), Hi = /(p(X,F),p(F,X)), H2 = /(p(X,F),p(F,Z),p(Z,X)), 
.... Using the slightly strengthened embedding relation no Ai would be embed- 
ded in any Aj with j ^ i, while using Definition unmodified we have, e.g.. 
Hi <* H2 (but not Ho <* Hi or Ho <* H2). 

Theorem 3. <* is a wbr on expressions. Additionally, if diF and :<$ are wqo’s 
then so is <1* . 



The proof can be found in | 



7 Discussion and Conclusion 

Of course <* is not the ultimate relation for ensuring online termination. Al- 
though it has proven to be extremely useful superimposed, e.g., on determinate 
unfolding, on its own in the context of local control of partial deduction, <* (as 
well as and <) will sometimes allow too much unfolding than desirable for 
efficiency concerns: more unfolding does not always imply a better specialised 
program. We refer to the solutions developed in, e.g., Similar problems 

can arise in the setting of global control and we again refer to ^or dis- 

cussions and experiments. Also, the issue of an efficient implementation of the 
homeomorphic embedding relation still remains open. (However, in Section | 
we have shown that the efficient way to use wfo’s, which avoids re-scanning the 
entire sequence upon refinement, has very undesirable properties.) 

For some applications, < as well as and <* remain too restrictive. In par- 
ticular, they do not always deal satisfactorily with fluctuating structure (arising, 
e.g., for certain metainterpretation tasks) The use of characteristic trees 
remedies this problem to some extent, but not totally. A further step to- 
wards a solution is presented in In that light, it might be of interest to study 
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whether the extensions of the homeomorphic embedding relation proposed in 
and ^3 (in the context of static termination analysis of term rewrite systems) 
can be useful in an online setting. 

In summary, we have discussed the relation between wqo’s and wfo’s. We have 
illustrated that <, despite its simplicity, is strictly more generous than the class 
of monotonic wfo’s and simplification orderings combined. As all the wfo’s used 
for automatic online termination (so far) are actually monotonic, this formally 
establishes the interest of < in that context. We have also compared to techniques 
based upon nearly- foundedness, and have shown that such techniques — contrary 
to < — can lead to the undesirable property of strict over-eagerness. 

We have also presented new embedding relations <+, <var and <*, which in- 
herit all the good properties of < while providing a refined treatment of (logical) 
variables. We believe that these refinements can be of value in other contexts and 
for other languages (such as in the context of partial evaluation of functional-logic 
programs or of supercompilation of functional programming 

languages, where — at specialisation time - variables also appear). For instance, 
one can simply plug <* into the language-independent framework of 

We also believe that <* provides both a theoretically and practically more 
satisfactory basis than <+ or <. We also believe that <* can play a contributing 
role in other areas, such as controlling abstraction and ensuring termination of 
infinite model checking. 
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Abstract. In this paper we study how to verify that a pure Prolog pro- 
gram has solutions for a given query. The detailed analysis of the fail- 
ure/success behaviour of a program is necessary when dealing with trans- 
formation and verification of pure Prolog programs. In a previous work 
we defined the class of noFD programs and queries which are char- 
acterized statically. We proved that a noFD query cannot have finitely 
failing derivations in a noFD program. Now, by introducing the concept 
of a set of exhaustive tests, we define the larger class of successful predi- 
cates. We prove that a noFD terminating query for successful predicates 
have at least one successful derivation. Moreover we propose some tech- 
niques based on program transformations for simplifying the verification 
of the successful condition. 

Keywords and Phrases: pure Prolog programs, failure/success analysis, 
program transformations 



1 Introduction 



When developing a logic program we, more or less explicitly, have to analyze it 
with respect to correctness, termination properties and the existence of success- 
ful computations. On correctness and termination verification there have been 



rather many proposals such as 



While for distinguishing failing 



and successful computations or for ensuring the presence of successes in a com- 
putation, very little is available, both in terms of methodology and tools. We can 
illustrate the kind of information on derivations we would like to infer through 
a few simple examples. 



Example 1. Let us consider 



reverse ( [] , [ ] ) . 

reverse ( [X |Xs] , Zs) ^ reversefXs, Ys) , append(Ys, [X], Zs) . 
app( [] , Ys, Ys) . 

app([X|Xs], Ys, [X|Zs]) <— appCXs, Ys, Zs) . 

with the following modes and types: reverse{+ : List, — : List) and app{+ : 
List,+ : List, — : List), where -1- : List means input term typed as a list and 
— : List means output term typed as a list. 

This well-known program shows the simplest case: a program which does not 
produce finitely failing derivations (FDs) when correctly queried. □ 



P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 219-^^1999. 
(c) Springer-Verlag Berlin Heidelberg 1999 
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In a previous work we have given a sufficient condition for ensuring that a 
given program and query are without failures, namely they cannot have finitely 
failing derivations (noFD). Basically we formalize the following two observations. 
Let us consider reverse (or app), it is defined for any input in the specified mode 
and type, hence any correct query cannot cause a failure in input. Furthermore 
output terms in the body of its clauses are “new” variables, not appearing to the 
left, hence reverse cannot cause a failure in output since when the LD-resolution 
will reach the output terms, they will be still variables and then instantiable. 
As a consequence a well-typed query with “new” variables in output will not 
have FDs. The condition we give in Q is very restrictive, since we want it to 
be simple and verifiable from the text of the program. 

The requirement of not having FDs is useful in program transformations 
when we assume a Prolog interpreter, (this was our main motivation in 
and when reasoning on efficiency, but it is too strong in general. In fact in many 
cases we cannot expect the program not to have FDs, we would be satisfied to 
know that the program has at least one successful derivation for a given query. 

Example 2. Let us consider 

delete! [] , X, [] ) . 

delete! [X |Xs] , X, Ys) ^ delete!Xs, X, Ys) . 

delete! [X jxs] , Z, [X|Ys]) ^ X yf Z, delete!Xs, Z, Ys) . 

with mode and type delete{+ : List, + : Any, — : List). 

This program can produce FDs since it contains unification tests, namely X. Z, 
which can fail. But, by examining also the heads of the clauses, we could observe 
that all possible cases are defined, namely they are exhaustive on the input types. 
Hence, since the mode and type guarantee termination, delete can be queried 
with at least one successful derivation. □ 



Example 3. Now let us consider: 

posPivot!L, Pos) <— oddLengthfL, Length), 

Pos is Length div 2 +1. 
posPivotfL, 0) ^ evenLength!L, Length). 
oddLengthfL, N) lengthfL, N) , odd!N) . 
evenLength!L, N) length!L, N) , even!N) . 

with modes and types: posPivot{+ : List, — : Nat), evenLength{+ : List, — : 
Nat), oddLength{+ : List, — : Nat), length{+ : List, — : Nat) and euen(-|- : 
Nat), odd{+ : Nat). 

In this program the predicates evenLength{L, N) and oddLength{L, N) are used 
as tests and they can cause FDs. But also in this program we could show that 
the tests are exhaustive on the input types. Since the modes and types ensure 
termination, we can also show that posPivot can be queried with at least one 
successful derivation. □ 
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From these few examples it should be evident that the failure/success analysis 
of a logic program is not such a simple task. The simple condition we define 
in for ensuring that a program has no FDs, applies only to a rather small 
class of programs. Many programs have FDs since they use tests, which by 
definition are assumed to fail for some inputs. On the other hand, programs 
with tests generally use them to define a different behaviour for each possible 
input, namely they generally use a set of exhaustive tests. Hence in order to 
recognize that a program has at least one solution for a given query, we have to 
be able to recognize a set of exhaustive tests. Tests are not easy to characterize, 
they can be predefined and with input only, as in Example^ or defined by the 
user and supplying also an output, as in Example H In this paper we intend 
to explore all these cases and to give a general methodology for failure/success 
analysis. 

In Section 2 we set some notation and recall the definitions of noFD program 
and query. In Section 3 we give a general definition for a set of exhaustive tests 
for a predicate and we use it to define the class of successful predicates. We prove 
that a noFD query, defined by successful predicates, has at least one successful 
LD -derivation, if it universally terminates. In section 4 we propose some tech- 
niques, based on program transformations, for simplifying the verification of the 
successful property and describe a methodology for verifying that a predicate is 
successful. Conclusions follows in section 5. 

2 Basic Notions 

Given a substitution rj and a set of variables X, we denote by rj\x the substitution 
obtained from rj by restricting its domain to X. Given an expression (term, atom, 
query ,. ..) E, we denote the set of variables occurring in it by Var{E). We often 
write rj\E to denote rj\ var(E)- A renaming is a substitution which is a permutation 
of its domain. We write E ^ E' to denote that E and E' are variant expressions, 
that is there exists a renaming p such that E — E' p. When a renaming of E 
maps Var{E) in “new” variables we call it a new renaming of E and we speak 
of Ep as a new variant of E. 

We consider definite logic programs executed by means of LD -resolution, 
which consists of the usual STD-resolution combined with the leftmost selection 
rule as Prolog interpreters do. Throughout the paper we use queries instead of 
goals. A query is a sequence of atoms or fail, fail stands for the query associated 
to a failure and □ for the empty query. An T£)-derivation ending with □ is a 
successful LD -derivation, one ending with fail is a failing one (ED). 

We consider the property of universal termination for a query Q in a pro- 
gram P, which means that the LD-tree of Q in P is finite. This termination 
property has been widely studied and it ensures termination with a 

Prolog interpreter. 

We denote sequences by bold characters and we call p(X) a general atom 
when its terms are all distinct variables. We use identifiers to label clauses and 
derivations. Then I : Q R stands for ”an TP-derivation, I, of the query 



222 



Annalisa Bossi and Nicoletta Cocco 



Q in P, which ends in the query R and a is the composition of the relevant and 
idempotent mgu's applied during the derivation”. Similarly Q | — *^p □ denotes 
a successful PP-derivation of Q in P with c.a.s. (T|q. Q | — R denotes one 
derivation step, we say that it is non-trivial if R is not fail. The length of an 
PP-derivation I is denoted by | / |. The rest of the notation is more or less 
standard and essentially follows 

We make use of the notion of modes and types introduced in We 

consider a combination of modes and types and adopt the following assumption: 
every considered relation has a fixed mode and a fixed type associated with it. 
This assumption allows us to talk about types of input positions and of output 
positions of an atom. For example, app{+ : List, + : List, — : List) denotes 
a ternary relation app with the first two positions moded as input and typed 
as List and the third position moded as output and typed as List. A similar 
denotation is called a directional type in ^From we take also the notion 
of well-typed query and program, which guarantees that mode and type properties 
are preserved through PP-resolution, and from Q the notion of simply moded 
clause and query. Here we recall only the main definition of well-typed program. 
We need type judgments, namely statements of the form s : S ^ t : T. A type 
judgment is true, |= s : S ^ t : T, iff for all substitutions 9, s9 G S implies 
t9 G T. To simplify the notation, when writing an atom as p(u : S,v : T), we 
assume that u : S is a sequence of typed terms filling in the input positions of p 
and V : T is a sequence of typed terms filling in the output positions of p. 



Definition 1 (well-typed query, clause, program Q). 

- A query pi{h : Ii,Oi : Oi), . . .,p„(in : In,On : On) is well-typed iff 
for j G [l,n] 

H • • ■) Oj~i ■ Oj-i ^ ij ■ Ij- 

A clause Pq(Oq . Oq, in+l ■ In+l ) ^ Pl(ll-Ii,Oi . O^),..., Pn(^n ■ In, ®n . On) . 
is well- typed iff for j G [1, n -|- 1] 



H Oq : Oq, . . : Oj_i ^ ij • Ij- 

— A program is well- typed iff every clause of it is. 



□ 



Note that a query with only one atom is well-typed iff this atom is correctly 
typed in its input positions. Note also that being correctly typed in input does 
not necessarily implies groundness in input. For example p{[Xi, . . ., Xn],N) is a 
well-typed query wrt the directional type p{+ : List, — : Nat). 

Besides we need the following definitions. 

Definition 2 (simply moded sequence). Let P be a well-typed program and 
Q = Ri, . . ., Bm a well-typed query in P. The input (output) terms of Q, denoted 
by /n(Q)(Out(Q)), are the terms in input (output) positions in Q. 

Q is simply moded iff output positions are filled in with distinct variables which 
do not appear to the left, namely Vj G Out{Bj) = V ar{Out{Bj)) ; if 

Xi, . . ., Xk are the output terms in Bj, then Xi Xh, for i h, i,h G [1, k]; 
and Out{Bj) n {V ar{Bi, . . ., Rj-i) U Var{In{Bj))) = 0. □ 
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A simply moded sequence is exactly what is called simply moded query in Q. 

Definition 3 (input-correct and simply moded instance). Let A be an 

simply moded atom and a a substitution. We say that Aa is an input-correct 
and simply moded instance of A iff Aa is correctly typed in input and Out{Aa) 
is a new variant ofOut{A). □ 

Intuitively in an L£)-derivation, FDs may happen when some term is instantiated 
in an ’’incorrect” way, namely this means that for avoiding FDs, inputs must be 
correctly given, while outputs should be correctly instantiated by the evaluation. 

In we define an interesting class of programs: programs without failures 
(noFD programs). These programs have a clear functionality from input to out- 
put but they can be non-deterministic. They satisfy the strong property that, in 
an TD-derivation, for any selected atom correctly typed in input positions and 
with uninstantiated variables in output positions, there exists a unifying clause 
in P. 

Definition 4 (noFD program). Let P be a well-typed program. 

A clause c : i? <— Ai, . . ., A„. in P is without failures (noFD clause) iff 

1. c is simply moded (namely the sequence of atoms in the body, Ai, . . ., An, is 
simply moded and Var{Ln{H)) n Var{Out{Ai , . . ., A„)) = 0^; 

2. for all i G [1, n] and for any input-correct and simply moded instance A^a of 
Ai, there exists a clause in P whose head unifies with A^a. 

A predicate p in P is without failures (noFD predicate) iff all the clauses in (the 
deductive closure of) its definition in P are noFD ones. The program defining p 
is then a program without failures (noFD program). □ 

The condition for being noFD is local, namely each clause can be considered 
separately. Only atoms in the clause bodies and in the queries have to satisfy 
the restrictions, on the head atoms no restriction is required. Hence a well-typed 
program containing only facts is trivially noFD. 

We need also a similar condition on queries in order to guarantee that they 
do not introduce FDs. 

Definition 5 (noFD query). Let Q — Bi, . . ., Bm be a well-typed query. 

Q is without failures (noFD query) in a program P iff 

1. the query Q is simply moded; 

2. for j G [l,m] and for any input-correct and simply moded instance BjU of 

Bj, there exists a clause in P whose head unifies with Bja. □ 

Note that the first conditions in Definitions Q and Q are syntactic ones and 
then very simple to verify. The second conditions are more complex but, if a 
type definition is available, they can be statically verified since they just require 
unification. Hence the noFd-condition is decidable. For example given the defi- 
nition of list, we can easily verify that reverse and app in Example^are noFD 
programs. 



224 



Annalisa Bossi and Nicoletta Cocco 



Let us consider the two queries Qi = app{[X], [2], [XIXs]) and Q 2 = app{[l], 
[2], [XIXs]) with the app program in Example Q These queries are well- typed 
but they are not simply moded. Hence they are not noFD queries; they have no 
FDs though. This shows us that the noFD property is a sufficient condition, hut 
not necessary for the absence of FDs. 

noFD programs and queries form a rather restricted class since output terms 
in the query and in body atoms must always be uninstantiated variables. More- 
over tests are not allowed. Let us consider the programs in Examples They 
are not noFD. The presence of test predicates in the bodies makes impossible to 
the second condition in the noFD definition to be satisfied for all clauses. 

In Q we also prove the “persistency” of the noFD property through LD- 
derivation and the main result, namely that a noFD query in a noFD program 
cannot have FDs. 

Lemma 1. Let P be a noFD program and Q a noFD query in P . Let us consider 
one non-trivial LD-derivation step Q | — »p QL The query Q' is also noFD. □ 



Theorem 1. Let P be a noFD program and Q a noFD query in P. Then Q 
cannot have finitely failing derivations. □ 

In ^9 we also discuss the use of noFD condition both in the field of verification 
of program properties and in the field of program transformations. We give some 
examples showing how the noFD property can greatly simplify the applicability 
conditions of transformation operations, such as decreasing unfolding, replace- 
ment and switch, in transformation systems which take into account termination 
properties. 



3 Successful Predicates 

As we saw the first condition in Definition H is simple but restrictive since it 
forbids compound terms in output. This could be either bypassed by program 
transformation or weakened by allowing also restricted compound terms in out- 
put. 

The second solution could be obtained by considering nicely moded clauses 
and queries Q instead of simply moded ones in DefinitionsH&ndn This would 
allow also compound terms in output, but they must contain only “new” vari- 
ables. Nicely moded programs have been studied in connection with unification 
freedom properties. This enlargement would rather complicate the verification 
of the noFD property since we should check also the type structure in the com- 
pound terms. 

The first solution can be illustrated by means of a simple example. 

Example Let us consider 



last(L, E) 



reverse (L, [E I Xs] ) . 
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with directional type last{+ : List, — : Any) and reverse{+ : List, — : List). 
This program is not noFD since the atom reverse{L, [iil|Xs]) is not simply 
moded. But we could transform it into the equivalent program 

last(L, E) reverseCL, Zs) , selFirstCZs, E) . 
selFirst([X| Xs] , X). 

with directional type last{+ : List, — : Any), reverse{+ : List, — : List) and 
selFirst{+ : List, — : Any). 

This program is noFD. □ 

Hence by explicitly introducing subterm selectors and constructors it is possible 
to transform a non-noFD program into a noFD one. 

Let us consider now the second, more serious, restriction given by our noFD 
definition: using tests in a program prevents it to be noFD. In this section 
we define a class which is wider than the one of noFD programs and which 
characterizes a weaker property: the programs in the class can have FDs but, 
when the query universally terminates, it has at least one successful derivation. 
We call it the class of successful programs. In order to give a simple definition 
of such a class of programs, we need to define the property of a set of tests of 
considering all possible cases in input. 

First of all we need to identify tests. We do not give a definition of what a 
test is, for us it is just a predicate which can fail. Hence it cannot be noFD. The 
noFD property does not characterize non-failure (it is not a necessary condition), 
then also its negation, the non-noFD property, does not characterize the failure 
property (it is not sufficient). On the other hand the simplest heuristics for 
identifying tests among body atoms is to choose both non-noFD atoms (queries) 
and atoms which are noFD but their definition is not. In the following we assume 
that, given a program, we can partition the atoms in the clause bodies into tests 
and non-tests. 

Definition 6 (exhaustive tests). Let P be a well-typed program wrt the direc- 
tional type T and let p be a predicate defined in P by the clauses p(ti) ^ Ti, Bi., 
with i G [1, m]. 

{Ti,...,T^} are exhaustive tests for p wrt input types in T iff 
for any A, input-correct and simply moded instance of the general atom _p(X), 
there exists i, i G such that a = mgu{A,p{t\)) and Tia has at least one 

successful LD-derivation. □ 

Example 5. Let us consider the following trivial program 



p(x, 


Y, 


Z) ^ 


- X = 


Y, r(l, Z). 


p(a, 


B, 


Z) ^ 


- some 


(B), r(2, Z) 


p(b, 


a, 


Z) ^ 


- r (3, 


Z) . 


p(b, 


c, 


Z) ^ 


- r(4, 


Z) . 


some 


(b) 








some 


(c) 








r(X, 


Y) 


^ , 
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with directional type: 

T = p{+ : {a, b}, + : {a, b, c}, — : R),= (+ : Any, + : Any), some(+ : {a, b, c}), 
r(+:{l,2,3,4},-:i?). 

We identify X = Y and some{B) as tests since they are not noFD (condition 2 
in Definition ^is not satisfied). 

{X = Y, some{B), true, true} are exhaustive tests for p wrt input types in T. 
In fact input-correct and simply moded instances A of p{Xl, X2, X3) are such 
that the first term of A is in {a, b} and the second in {a, b, c}. 

Let us consider all possible cases. 

1) A — p{a, a, T) or A — p{b, b, T), then the first definition of p can be chosen 
and CT = mgu{A,p{X, Y, Z)), with a = {X/a, Y/a, TjZ} or a = {Xjb, Y jb, TjZ}. 
In both cases the test {X = Y)(t is successful. 

2) A = p{a,b,T) or A = p{a,c,T), then the second definition of p can be 
chosen and a — mgu{A,p{a, B, Z)), with a — {B/b,T/Z} or a = {B/c,T/Z}. 
In both cases the test some{B)a is successful. 

3) A = p{b,a,T), then the third definition of p can be chosen and cr = 
mgu{A,p{b, a, Z)), with a = {T/Z}. The test {true)a is successful. 

4) A = p{h,c,T), then the forth definition of p can be chosen and cr = 
mgu{A,p{b, c, Z)), with cr = (T/Zj. The test {true)a is successful. 

Since the condition in DefinitionHis satisfied, the tests are exhaustive. □ 

The previous example shows that we can always introduce a dummy test “true ” 
in a clause in order to complete the set of exhaustive tests associated to a 
predicate p with types in T. When p is defined also by facts, the introduction of 
the dummy test “true” is necessary for satisfying Definition^ 

Verifying exhaustiveness of tests for a given predicate and input types is not 
easy, it is a semantic condition and not decidable in general, as shown in 
In the following Section we will discuss this issue by showing cases in which 
the verification is simple and we will propose simplifications which can help in 
the verification. For the moment we assume to be able to verify the exhaustive 
property when necessary. 

Since we assume that we can partition the body atoms into tests and non- 
tests, we can restrict the deductive dependency relation to non-test predicates. 



Definition 7 (s-dependency) . Let P be a well-typed program and p a predicate 
defined in P by the clauses p{ti) Ti, Bi., with i € [1, m], and Ti tests. 
p s-depends on q iff q is a predicate symbol in Bi with i G [1, m]. 

-<P denotes the transitive closure of s-dependency in P . 

sDep{p) is the set of predicates from which p s-depends also indirectly: sDep{p) = 

{q\p<pq}. □ 

Now we can give the main definition. 

Definition 8 (successful predicate). Let P be a well-typed program wrt the 
directional type T . 

A predicate p in P is successful wrt the input types in T iff 
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for all the predicates q in sDep{p) U {p} the following two conditions are 
verified: 

let q{ti) <— Ti, Bi., with i G [1, »Ti], be the clauses defining q in P, 

1. Ti, . . Tjn are exhaustive tests for q wrt input types in T; 

2. (LioFD conditions^ for i € [1, m] 

— the sequence Bi is simply moded; 

— Var{Out(Bi) n {Var{In\q{U))) U Var(Ti)) = 0; 

— for all £) G Bi and for any input-correct and simply moded instance Da 

of D, there exists a clause in P whose head unifies with Da. □ 

The intuitive idea is that if p is a successful predicate, for any input-correct and 
simply moded query p(t), there is at least a clause in the definition of p which is 
applicable, whose tests are successful and which produces a non-finitely failing 
derivation (noFD conditions on the atoms in the body which follow the tests). 
ExamplesHHare successful predicates. 

Note that we require that tests are leftmost in the clause bodies. This is 
clearly a restriction, since tests can appear also in other positions. For example 
let us consider a non-tail recursive definition of the maximum element in a list 
of integers. On the other hand this requirement could be dropped and we could 
give a more general (yet more complex) definition and proof. 

Note also that a noFD predicate which is defined for any well-typed input is 
a successful predicate. In fact we can always introduce the dummy test true in 
all the clauses, thus having tests which are trivially exhaustive. For this reason 
also reverse and app in Examplejare successful predicates. 

For successful predicates we can prove that any noFD query which universally 
terminates has at least one successful derivation. We need two simple Lemmata 
first. 

Lemma 2. Let Q he simply moded and a be a substitution such that Var{a) O 
Var{Q) C {Var{In{Q)) — Var{Out{Q))) . Then Qct is simply moded. 

Proof. Immediate from the definition of simply moded sequence and the condi- 
tion on the substitution a. □ 

Lemma 3. Let Qi and Q 2 be simply moded and such that Var{Qi) DVar{Out 
(Q2)) = 0- Then Q1Q2 is simply moded. 

Proof. Immediate from the definition of simply moded sequence. □ 

Theorem 2 . Let Q be a noFD query in P . If Q is universally terminating in 
P and all the predicates in Q are successful in P wrt the input types, then Q 
has at least one successful LD-derivation in P . 

Proof. See the Appendix. □ 

4 How to Verify that a Program is Successful 

The conditions in DefinitionHare not so easy to verify. Problems are in condition 
1, namely how to single out tests and to prove that they are exhaustive. In this 
section we propose some techniques for simplifying such task and a strategy for 
the failure/success analysis. 
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4.1 Accepted input types 

In Definitions we state that a noFD predicate is successful only if it is 

defined for any correct input wrt to its directional type. A simple example will 
show the point. 

Example 6. Let us consider the following simple program 
last([X] ,X) . 

last([X, Y| Xs] , E) ^ last([Y| Xs] , E) . 
with directional type last(+ : List, — : Any). 

last is noFD but not successful. In fact by introducing the dummy test true we 
get the program 

last([X],X) <— true. 

last([X, Y| Xs] , E) <— true, last ([Y I Xs] , E) . 

where {true, true} are not exhaustive tests for last wrt the input types since 
last is not defined for empty lists. 

But we can restrict the directional type associated to last to last{+ : List~^ , — : 
Any), where List'^ = List — {[]}. 

Now the program is both noFD and successful. □ 

Often the directional type associated to a predicate is actually larger than the 
types for which the predicate is defined. We can weaken the requirements in 
Definition^by introducing the notion of input types accepted by a predicate. 

Definition 9 (accepted input types). Let P be a well-typed program and 
p a predicate defined in P by the clauses p{tn, . . .,tin, Sn, . . ., Sir) <— Bi., with 
i G where tik, k G [l,n], are input terms and Sih, h G [l,r], output 

terms. Let Tk, for k G [1, n], be the types associated to the input positions in the 
directional type of p. 

The input types accepted by p, ATk, for k G [1, n], shortly accepted input types, 
are given by the sets of all the instances of terms in the k-th input positions of 
the heads of the definitions of p which belongs to Tk : 

ATk = {U^{tikP,.-.,tmkP})nTk. □ 

In a well-typed program the accepted input types can be subsets of the input 
types declared in the directional type. They are the sets of terms which can be 
effectively used as inputs when querying the predicate. 

Abstract Interpretation techniques can be used for inferring type information 
for a program with these techniques accepted input types are inferred. 

In order to automatize the verification of the successful property, we could then 
exploit tools for Abstract Interpretation. 

The definitions of exhaustive tests and successful predicate can be restricted 
to accepted input types. In this case the condition on exhaustive tests in Defi- 
nition His simplified since there always exists a clause i G [1, m] and an mgu cr 
for any input-correct and simply moded instance of the predicate. 

Note that the property of being well-typed wrt a directional type is not 
preserved in general when we restrict the input types to the accepted ones. 
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Example 1. Let us consider the following program 
last([X] , X) . 

last ([XI Xs] , E) ^ lastCXs, E) . 

this predicate is well-typed wrt the directional type last{+ : List, — : Any) but 
it is not well-typed wrt last{+ : List~^,— : Any) which is the directional type 
we obtain when we restrict it to accepted input types. □ 

The mismatch between the declared directional type and the accepted input 
types always causes problems wrt failure/success analysis: wrt the first direc- 
tional type last is not noFD, in fact the second condition in Definitionjis not 
satisfied since in the body can be an empty list. 

In the following we assume that the directional type associated to a predicate 
are already restricted wrt accepted input types. 



4.2 Exhaustiveness of tests 

A major difficulty in using Definitionjis the identification of exhaustive tests. 
We need to be able to single out some body atoms in a predicate definition and 
to prove that they are a set of exhaustive tests for that predicate. Atoms which 
are eligible as tests are the ones which do not satisfy noFD conditions (condition 
2 in Definition^. Proving that they are exhaustive is not trivial. It is a semantic 
condition and not decidable in general, as shown in but in most practical 
cases the conditions in DefinitionHcan be verified. 

Let us consider Example^ odd and even are non-noFD predicates, hence also 
oddLength and evenLength which depend on them are non-noFD. In the defini- 
tion of posPivot we choose them as tests. We should prove that {oddLength{L, 
Length), evenLength{L, Length)} are exhaustive for posPivot wrt input types. 
This means to prove that VL £ List, \ L \= n G Nat and then Vn £ Nat, even{n)y 
odd{n). In these very general cases, specifications could give us the knowledge 
we need for our proofs. 

We could also study a priori a set of predicates and prove that for any input 
value at least one of them is successful. This would give us “a tool” for verifying 
the condition in Definition J An appropriate set of such “tools” could capture 
most sets of exhaustive tests. 

Among the most common sets of tests are arithmetic tests. Let us consider 
the set {x < y,x > y}. We can verify once for all that for any pair x,y G S, 
where S is any subset of Int, at least one inequality is true and successful with 
a Prolog interpreter. Similarly for {x < y,x > y} and {x < y,x > y}. 

Example 8. Let us consider the program 

gcd(X, 0, X). 

gcd(X, Y, Gcd) <— mod(X, Y, Z) , gcd(Y, Z, Gcd) . 

mod(X, Y, X) ^ X<Y. 

mod(X, Y, Z) ^ X>=Y, XI is X-Y, mod(Xl, Y, Z) . 
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with directional type gcd{+ : Int'^,+ : : Int~^) and mod{+ : Int'^,+ : 

Int'^, — : Int'^), where Int'^ is the set of non-negative integers. 
mod contains X < Y and X >= Y. Any correct application of the clauses 
defining mod will instantiate both X and Y to terms in We can then use 

our previous result and easily prove that such tests are exhaustive on the input 
types and then both gcd and mod are successful predicates. □ 

Another common set of tests which we can easily study a priori is given by uni- 
fication tests, namely {x = y, x y}, with x,y G T and T any type. Unification 
is decidable, then at least one of the two is true and successful. 

If we allow negation in tests, we could consider also user-defined ground 
tests such as for all predicate symbol p {p{x),not p(x)}, with x G T and T 
ground types. Since negation-as-failure for ground atoms corresponds to classical 
logic, we know that at least one of the two is true and successful with a Prolog 
interpreter. 

Example 9. Let us consider 

split! [] , Set2, [] , [] ) . 
split (Setl, [] , Setl, [] ) . 

split ( [X |Xs] , Set2, [X | Complement] , Intersection) ^ 
not memberCX, Set2) , split (Xs , Set2 , Complement , Intersection) . 
split ( [X |Xs] , Set2, Complement, [X | Intersection] ) ^ 
memberCX, Set2) , splitCXs, Set2, Complement, Intersection). 
memberCX, [X|Xs]). 

memberCX, [Y |Ys] ) ^ memberCX, Ys) . 

with directional type split{-\- : GroundList, -\- : GroundList, — : GroundList, — : 
GroundList) and member {-\- : Ground, -\- : GroundList). 

This program contains tests predicates, namely member{X, Set2) and not member 
(X, Set2), which for any correct use of split will become ground. By our previ- 
ous observation we can easily prove that such tests are exhaustive on the input 
types. Then we can prove that split is successful. □ 

By knowing more on the interpreter we could enlarge our set of “tools” . 

Example 10. Let us consider {odd{x) , even{x)} , with x G Nat. Suppose we know 
that for each choice of x for the Prolog interpreter at least one of the two is 
successful. Then when considering the program 

doubleEvenC [] , [] ) . 
doubleEvenC [X |Xs] , [X |Ys]) 
doubleEvenC [X |Xs] , [Y |Ys] ) 
doubleEvenCXs , Ys) . 

with directional type doubleEven(-\- : NatList, — : NatList) and even{-\- : Nat), 
odd{-\- : Nat)-, 

we could easily verify that {true, odd{X) , even{X)} are exhaustive for 
doubleEven, with X G Nat. □ 



oddCX) , doubleEvenCXs, Ys) . 
evenCX) , Y is X*2 , 
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4.3 Input-normalization 

In order to use the predefined knowledge in the “tools” we have to instantiate 
our set of tests with input types. But instantiation is often not enough in order 
to recognize a well-known case. Let us consider Example H There is only one 
explicit test, X ^ Z. Nevertheless we should recognize that delete is using 
unification tests, where the complementary test X = Z is implicit in the head 
of the second clause. To make it easier (and more automatizable) we introduce 
a transformation for normalizing input arguments in a program. 

Definition 10 (input-normalized definition). Let P be a well-typed program 
and p(ii, . . ., in, Oi, . . ., Or) a predicate defined in P, where ik, with k € [1, n], 
are the input positions and Oh, with h G [l,r] the output positions in p. Let 
V = {^ 1 , . . ;Xn} be a set of new variables wrt p, namely variables which do 
not appear in the definition of p. 

The input-normalized definition of p, p^ , is the program obtained by substituting 
each clause in the definition of p: p(fi , . . ., Si, . . ., Sr) r- D. 
withthe correspoudmp input-normalized clause.' p(Xi, ..., X„, Si, ..., Sr) Xi — 
tl, . . ., Xn — tn, D. 

The program thus obtained is input-normalized wrt p. V is the set of normalized 
input variables for p^ . 

Xk = tk, for k € [1, n], are the input equalities in each clause in the definition 
of p^ , with directional type = (-1- : Tk, — : Tk), where Tk is the type associated 
to the k-th input position. □ 

Input-normalization is similar to a transformation, used both in program trans- 
formation techniques and in Abstract Interpretation, which we could call “head- 
normalization” . In such transformation the resulting clauses heads must have 
only distinct variables as arguments and this is obtained by introducing appro- 
priate equalities in the clauses bodies. 

Let us now briefiy discuss the properties of input-normalization. 

Lemma 4. Let P be a well-typed program and p a predicate defined in P . Let 
us associate in p^ , to each input equality Xk = tk, the directional type = (-1- : 
Tk, — : Tk), where Tk is the type associated to the k-th input position in the 
directional type ofp. Then p^ is well-typed. 

Proof. Trivial, by Definition of well-typed clause. □ 

Lemma 5. Let P be a well-typed program and p a predicate defined in P. p^ is 
clause-wise equivalent to p. 

Proof. By unfolding the input equalities in each clause in p^ , we obtain the 
clauses of p again. On the other hand we already proved Q that unfolding 
preserves both c.a.s. and universal termination. □ 

Note that the property of being noFD is not preserved through input-normali- 
zation. In fact even if the original predicate p is noFD, p^ can be non-noFD 
since in general input equalities do not satisfy the simply modedness condition 
in Definition^ 
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Example 11 . Let us define app^ wrt the directional type app{+ : List,+ : 
List, — ; List). 

appCXi, X2, Ys) ^ Xi = [] , X2 = Ys. 

appCXi, X2, [X |Zs]) <— = [X |Xs] , X2 = Ys, app(Xs, Ys, Zs) . 

app^ is not noFD. It does not satisfy the first syntactic condition in Definition 
Jsince compound terms are in output in the input equalities in the bodies. □ 

We assume that input-normalized programs always refer to the accepted input 
types of the original program. Let us consider again Example^ 

Example 12 . After input-normalization we obtain: 

delete(Ai,A2, []) ^ Ai = [], A2 = X. 

deleteCAi, A2, Ys) ^ Ai = [X |Xs] , A2 = X, 

deleteCXs, X, Ys) . 

delete (Ai, A2, [X |Ys]) ^ Ai = [X |Xs] , A2 = Z, X yt Z, 
deleteCXs, Z, Ys) . 

We can determine tests predicates by composing the input equalities introduced 
by input-normalization with atoms in the clause bodies for which noFD condi- 
tions are not satisfied. Namely we consider the tests: 

Ti = (Ai = [],A2 = A), 

T2 = (Ai = [A| As],A2 = A), 

T3 = (Ai = [A I As], A2 = Z,X^ Z). 

Note that both the input equality A2 = A in the second clause and the built-in 
predicate A yZ Z in the third clause have a directional type (-1- : Any, -|- : Any) 
which is induced by the well-typing condition. 

Let us consider an input-correct and simply moded instance of delete. Either Ai 
is an empty list and the first test Ti is successful, or Ai is a non-empty list. In 
this second case A G Any and we have an alternative between (A2 = A) and 
(A2 = Z^X yZ Z). By unfolding A2 = .^ in the second test we get to the two 
tests (A2 = A) and (A yZ A2), which have directional type (-1- : Any, -I- : Any). 
Since we know that they are an exhaustive set of tests (unification tests), also 
{Ti,T2,T3} are exhaustive for delete^ . 

The other two (noFD) conditions are easy to verify on the recursive atoms. □ 



4.4 Input-subsumption 

In order to make easier to prove the property of being exhaustive tests for a 
predicate, it is often useful to “simplify” the set of clauses we consider. To this 
purpose we introduce the following definition. 

Definition 11 (Clause input-subsumed by a fact or a clause). Let P be 

a well-typed program. Let Ci : A. be a fact, C2 : iY B. and C3 : K ^ A. be 
clauses in P which define the same predicate, namely A = p(ti), H = p(t2) and 
K = p{ts). 

Clause C2 is input-subsumed by the fact Ci iff there exists an input substitution 
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6 such that A9 = H . 

Clause C3 is input-subsumed by clause C2 iff there exists an input substitution 6 
such that HO — K. □ 



Example 13. Let us consider the trivial program 



p(x. 


Y). 




p(a. 


Y) ^ 


- r(a) , s(Y) . 


p(X, 


b) V 


- r(X). 


p(a. 


b) ^ 


- r (a) , p(a, Y) 


r (b) 






s(b) 







well-typed wrt the directional type p[+ : Const, — : Const),r{+ : Const), s(— : 
Const). 

Clause 2 is input-subsumed by fact 1. 

Clause 4 is input-subsumed by clause 3. □ 

We have extended the usual concept of subsumption to fit the verification of 
the successful property. We are not interested in c.a.s. but in characterizing the 
presence of at least one successful derivation for each well-typed input substitu- 
tion. A fact always produces a successful derivation, then it can input-subsume 
a clause independently from its body. Similarly for two clauses, if the one ac- 
cepting a more general input produces a successful derivation, then the other 
one becomes irrelevant. Input-subsumption can be used to prune the program. 
If we can prove that a pruned definition of a predicate is successful, then also 
the original definition is successful. This means that we may simplify the ver- 
ification of Definition H by first pruning the program of some input-subsumed 
clauses. The simplification phase must be applied before input-normalization; 
after input-normalization input-subsumption becomes trivial and useless. 

Example I 4 . let us consider: 

choose(Low, High, Low). 

choose (Low, High, X) ^ Low < High, L is Low +1, 
choose(L, High, Low). 

with directional type choose{+ : Int, + : Int, — : Int). 

This program is non-deterministic and the second clause is input-subsumed by 
the first one which is a fact and then noFD. Hence we can conclude that also 
choose is successful. □ 

By pruning input-subsumed clauses we often succeed in reducing the non-trivial 
problem of verifying that a predicate is successful, to the much simpler problem 
of verifying that the pruned predicate is noFD. 
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4.5 Analysis strategy 

We now propose a strategy for the failure/success analysis which allows us to 
exploit the simplifications already presented. 

Given a predicate p in P the analysis could proceed as follows: 

1. check that we are referring to accepted input types for p (for instance by 
Abstract Interpretation); 

2. check if the predicate p is noFD; 

3. otherwise prune p by eliminating some input-subsumed clauses and check if 
it is now noFD; in this case we can state that the predicate is successful; 

4. If not, for all predicates q in sDep{p) U {p}\ 

— input-normalize; 

— single out the tests in the bodies of the definition clauses (the input equal- 
ities plus the body atoms which do not satisfy the noFD conditions); 

— prove that they are exhaustive (with some predefined knowledge); 

— prove that the noFD conditions in Definition^are verified; 
in this case we can state that the predicate is successful. 

With this strategy the verification of the successful condition is done only when 
the noFD property is not sufficient. 

Step (1) is optional, but it can help to verify the next conditions. 

The pruning step (3) can be performed in many ways in general, namely, given 
a predicate definition, it may be possible to identify many subsets of clauses with 
the property that each clause in the predicate definition is input-subsumed by 
at least one clause in the subset. We might need to explore this nondeterminism 
in order to find a solution to the failure/success analysis. The simplest case is 
when we succeed in reducing our initial problem of verifying that a predicate is 
successful to the much simpler one of verifying that it is noFD. 



4.6 Applications 

The property of being successful can be useful in the field of program verification. 
Let us assume to have a program which is partially correct wrt a specification 
and a query which is both universally terminating and partially correct wrt the 
specification. Then, if we prove that the query is noFD and the predicates in 
the query are successful, Theorem H guarantees the existence of at least one 
correct c.a.s. This corresponds to give a proof of completeness with respect to 
both the Herbrand semantics and the S-semantics (the c.a.s. semantics). In fact 
for a ground query we are exactly proving completeness, and in general we are 
proving that the model of the program is not empty wrt the query. 

Also in the field of program transformations being successful can be use- 
ful in particular for switching atoms in the clause bodies. In | we consider 
left-terminating programs and we define a sufficient condition for switching 
atoms while preserving left-termination. This condition for switching the atom 
A with i? in a clause c : iL <— J, A, K. depends on the property of A of being 
“non-failing” , namely for each grounding substitution 9, such that Dom(9) = 
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Var{In{H) , 3 , In{A)) and 39 G Mp, there exists 7 such that A9^ G Mp, where 
Mp is the least Herbrand model of P. This intuitively means that if A is the 
selected atom in an TD-derivation, because c was used as input clause in a pre- 
vious derivation step, then the computation of A will eventually succeed. This 
is a “semantic” condition which is not easy to verify in general. But if we prove 
that the query A is universally terminating and noFD and the predicate in A is 
successful, then the non-failing condition is guaranteed. 

Example 15. Let us consider an example of transformation given in The 
following program defines the predicate goodpath{X, Xs) which relates a node 
X with a list Xs of “good” nodes which are connected to X. 

1: pathCX, [X]). 

2: pathCX, [X|Xs]) ^ arc(X, Y) , path(Y, Xs) . 

3 : goodlist ( [] ) . 

4: goodlist ( [X |Xs] ) ^ good(X) , goodlist (Xs) . 
d: goodpathCX, Xs) ^ path(X, Xs) , goodlist (Xs) . 

The directional type is path(-|- : Const, — : List) , goodlist : List) , goodpath{+ : 
Const, — : List), arc{-\- : Const, — : Const), good{-\- : Const). 

The predicates good and arc are test predicates defined in the program. 

In ^3 we consider a transformation which repeatedly unfold the body atoms in 
d until we get to: 

dl :goodpath(X, [X]) <— good(X) . 

d2:goodpath(X, [X |Xs] ) <— arc(X, Y) ,path(Y, Xs) , good(X) , 
goodlist (Xs) . 

In order to optimize the program by folding with d, we need to switch path{Y, Xs) 
and good{X) in d2. 

Hence we need to prove that path{Y, Xs) is non-failing in d2, namely that 

a) for each grounding substitution 9, such that Dom{9) = {X,Y} and 
Y9 G Const, path{Y, Xs)9 is a noFD query and 

b) path is a successful predicate. 

(a) is trivial. For (b) let us consider the definition of path given by clauses 1 and 
2. We can prune 2, since it is input-subsumed by the fact 1. Hence we obtain a 
noFD program given by a single fact, which implies that path is successful. □ 

5 Conclusion 

In program verification and transformation it is important to identify both the 
queries which have successful TD-derivations and those which have also finitely 
failing LD-derivations. 

In a previous work we have defined the class of noFD programs and queries 
Q which have the property of not having finitely failing derivations. In this 
paper we extend our previous work by defining the wider class of successful 
predicates which includes also programs using tests. We prove that noFD queries 
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for successful predicates have the property of having at least one successful 
derivation, if they are universally terminating. This property is more complex to 
verify than the noFD one, hence we suggest some techniques, based on program 
transformations, for simplifying the failure/success analysis. 

Our work is clearly related to those on cardinality analysis, for example in 
In these works an approximation of the number of c.a.s. for a query is 
estimated by means of Abstract Interpretation. 

Success analysis is interesting also for parallel execution optimization. In 
a technique is proposed for detecting programs and queries which produce at 
least one solution or do not terminate. The technique deals with programs con- 
taining tests and it is based on a different notion of mode and type information 
from ours. An algorithm is given for unification and arithmetic tests. The algo- 
rithm can decide if they “cover” a type by using Abstract Interpretation. The 
technique is implemented and a report on its implementation is also given. The 
technique proposed in is applicable to some of our examples: Hand, after 
input-normalization, H Since they do not consider the simple case when there 
are noFD, their rather sophisticated algorithm is applied also to noFD programs 
such asH 

In the Mercury language ^3 a nondeterminism analysis is implemented 
which is related with our work. Given a predicate p with mode m, there are 
six determinism categories for describing the result of any query for p and m. 
The six categories are: det (exactly one success), multi (at least one success), 
semidet (fail or exactly one success), nondet (fail or at least one success), failure 
(fail) and erroneous (run-time error) . Mercury can infer a category for p and m 
which is an approximation of the real one and can use such information for opti- 
mizing programs. The category multi corresponds to our successful class, while 
there is no Mercury category corresponding to our noFD class. It is not so easy 
to give a comparison with Mercury since no formal semantics is given, but we 
can make a few observations. The determinism analysis in Mercury is richer than 
our failure/success analysis, but it gives no information on the presence/ absence 
of FDs in a non- finitely failing LD-tree. It infers an approximation of the real 
determinism category and it could then be not precise. The inference of multi 
cannot be simplified by first pruning the program and then verifying the noFD 
property as we propose, nevertheless also in Mercury there are explicit ways to 
eliminate nondeterminism and to prune a program. In Mercury well-moding, and 
then well-typing, are not wrt a leftmost selection rule (Prolog rule). For Mer- 
cury it is sufficient that there exists an order of body atoms for which clauses 
are well- typed. 

Anyway the major difference between our work and related ones, is in pur- 
pose. The techniques based on Abstract Interpretation are generally meant for 
optimization in compilers, hence the emphasis is on automatizability and ap- 
proximation. We are more interested in program verification and transformation, 
hence generality and precision is our concern. 
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6 Appendix 

Theorem. Let Q be a noFD query in P . If Q is universally terminating in P 
and all the predicates in Q are successful in P wrt the input types, then Q has 
at least one successful LD-derivation in P. 

Proof. Let us assume that Q is universally terminating in P, then it has a finite 
LD-tree in P. 

The proof can be given by induction on the depth n of the LD-tree for a uni- 
versally terminating, noFD query Q whose predicates are all successful, 
n = 1. By contradiction let us assume that all the derivations have the form 
Q I — >p fail. Hence the first atom of Q can unify with no clause in P. But 
Q is noFD, hence well- typed, and its first atom is then input-correct and sim- 
ply moded. By the second property in Definition H we have a contradiction for 
a = e, the empty substitution. 

n > 1. Let is noFD, hence well- typed, and its first atom, 

Bi, is then input-correct and simply moded. Since the predicates in Q are suc- 
cessful there exists a clause Ci : p(ti) <— Ti,Ci. in P, i G standardized 

apart wrt Q, and a substitution a such that: a — mgu{Bi,p{tf)) and Tia has at 
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least one successful LD-derivation. Then, there exists the derivation Q | — ?p R, 
where R = (Ti, Ci, B 2 , ■ ■ Bn)cr and R is not empty. Let a be a computed an- 
swer substitution for Tia, we have the LD-derivation: 

Q Mp R h^P Q', with Q' = (Ci, B 2 , . . Br,)aa. 

Q' is still universally terminating and its predicates are successful since the pred- 
icates in Ci are in sDep{p) and p is successful. 

We prove that Q' is noFD. Then, by inductive hypothesis applied to Q', we have 
the thesis. 

— Since p is successful and Q a noFD query, Ci and B 2 ,. Bn are simply 
moded sequences. 

We assume standardization apart and a is a c.a.s. for Ticr, then 

— Var{aa)r\Var{B 2 , ■ ■ ., Bm) CVar{Bi). 

But Q is simply moded, then Var{Out{B 2 , ■ ■ ., Bm)) n Var{Bi) = 0, hence 
Var{aa)nVar{B 2 , . . ., Bm) Q {Var{In{B 2 , . . ., Bm))-Var{Out{B 2 , . . ., Bm))) 
and, by LemmaH 

(i) (i? 2 , . ■ ., Bn)(ra is simply moded and 

(ii) Out{B2 , . . ., Bm)(ra = Out{B2 , . . ., Bm)- 

— Var{aa) n Var{Ci) C Var{p{ti), Ti). 

Moreover Var{a) n Var(Q) = 0 and a = ■ ct|q. 

Since a = mgu{Bi,p{t{)) and B\ is in the query and it is simply moded, we 
have that V ar{a\a) H {V ar{Out{p(t\))) — Var{In{p(ti)))) = 0. 

Then Var{a\a) H Var(Ci) C Var{In{p(ti))) and Var{a\ciO() n Var(Ci) C 
yar(/n(p(ti)),Ti). 

Hence, since p is successful, V ar{a\aa)r\Var{Ci) C {Var{In{Ci))—Var{Out 
(Ci))) and, by LemmaH 

(iii) Cia\aOi = Cicra is simply moded. 

— Var{Cicra) fl Var{Qaa)) C Var(Biaa). 

Because of (ii) we have also that V'ar(i?i(ja)nyar(Out((i32, ■ ■ •, Bm)cra)) = 
0. Then, 

(iv) Var(Ciaa) n Var{Out{{B 2 , ■ ■ ., Bm)o'a)) — 0. 

Then, by (i), (iii), (iv) and LemmaH Q' is simply moded. 

Let us now prove that Q' satisfies also the second condition for noFD queries. 
(Ci, i? 2 , ■ ■ •, Bm)cra is simply moded, then for any atom D in (Ci, R 2 , ■ ■ ■, Bm)cra 
and for any input-correct and simply moded instance D(5 there exist D' in 
Ci, B 2 , ■ ■ Bm and a substitution f3' such that D(5 = D' (5' , and hence D' f3' 
is a input-correct and simply moded instance of D' . Hence the second condition 
for noFD queries immediately follows from the fact that p is successful and Q is 
noFD. □ 
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Abstract. This paper presents an automated method that deals with 
termination of constraint logic programs in two steps. First, from the text 
of a program, the method infers a set of potentially terminating classes 
using abstract interpretation and boolean mu-calculus. By “potentially” , 
we roughly mean that for each of these classes, one can find a static order 
over the literals of the clauses of the program to ensure termination. 
Then, given a terminating class among those computed at the first step, 
the second step consists of a “compilation” (or transformation) of the 
original program to another one by reordering literals. For this new pro- 
gram, the universal left-termination of any query of the considered class 
is guaranteed. The method has been implemented. 



1 Introduction 

Many research works have been devoted to termination analysis of (constraint) 
logic programs in recent years, as shown by the survey Q. For most researchers, 
the main problem is universal left-termination of a given class of queries. This is 
a somehow restricted view of logic programming. In Q, we addressed a broader 
question: given a CLP(y) program find the classes of queries for which universal 
left-termination is guaranteed. Here we go one step further: infer (automatically) 
larger classes of queries such that there exists a static reordering of the bodies 
of the clauses which insures universal left-termination. 

Example 1. Let us consider the following CLP(A/”) program, called power-4: 

rule ri : p(X,Y) : - s(X, Z), s(Z, Y). 

rule T 2 : s(0,0). 

rule T 3 : s(X -h 1, Y -h 2X -h 1) :-s(X,Y). 

The method described in Q can infer that x hounded, p{x, j/)” is a left- 
terminating query. Nethertheless, the resolution of the query <— y < 16, p{x, y) 
could terminate if in the clause defining the predicate p we prove s{z,y) before 
s{x,z). We would like to conclude that there are two terminating classes of 
queries: <— x bounded, p{x,y) and ^ y bounded, p{x,y). The new method we 
present in the following of this paper does this job. 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 240^B 
© Springer-Verlag Berlin Heidelberg 1999 
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The rest of the paper is organized as follows: section ^ recalls some basic 
notions about CLP(x) and approximations between two CLP systems. Sectio n [ 
summarizes our first results for the inference of left-termination conditions Q. 
Then, sections J and H present the two points of the new method: the infer- 
ence of larger classes of queries and the reordering of the literals inside clauses. 
Implementation issues are briefly discussed in section^ 



2 Preliminaries 
2.1 CLP(x) 

Let us remind some notations and conventions about CLP introduced in Q. 
For concision, we simplify the notations when we consider there is no ambiguity. 
Moreover, in concrete program examples we use the Edinburgh syntax. 

In the following, we consider idea| CLP systems without limit element, i 
(resp. x) represents a sequence of terms (resp. distinct variables). Let o be a 
CLP(x) object (a constraint, an atom, a goal or a clause). var{o) denotes the 
set of variables of o and o{x) means o where var{o) = x. If oi and 02 are two 
objects, oi = 02 means that oi and 02 are syntactically equal. The y-constraint c 
is x~solvable and 0 is a x~solution of c if 0 is a y- valuation s.t. y ^ c 9 . Otherwise 
c is y- unsolvable. Let ci and C2 be two y-constraints. We write c\ — C2 (resp. 
Cl C2) as a shorthand for y |= V[ci ^ C2] (resp. y |= V[ci C2]). 

We use the following structures (where the symbols have their usual inter- 
pretation) : 

- B = ({true, /a^se}; {0,1,-', A, V,^,<t4>};{^,=}), 

— N = (IN; {0, 1, -I-}; {>, =}) where IN is the set of natural numbers. 

In Af, for n G IN, n > 1, we write n (resp. nx) as an abbreviation for I-I-. . .-|-1 
(resp. a; a:), where I (resp. a:) appears n times. Let c(i) a A/"-constraint, 

y € X and m G IN. We say that y is bounded (resp. bounded by m) in c{x) if 
there exists n G IN such that c(i) — n>y (resp. c{x) — tn>y). 

On the set U of predicate symbols defined by a program P, we define the 
binary relation p q ii P contains a rule of the form p(ti) <—..., q(t,2), ■ ■ ■■ 
Let — denote the reflexive transitive closure of The relation p q ii p 
q A q p is an equivalence relation. We denote by p the equivalence class 
including p. 

A rule p{x) <— c,B is recursive if there is a predicate symbol q G p s.t. 
B = ... , q{y), .... A predicate symbol p is directly recursive ifp = {p} A{p ^ p). 
The predicate symbols jpi, . . .,Pn\ {n > 2) are mutually recursive ii p\ = . . . = 
Pn = jpi, . . . ,Pn\- A predicate p is recursive if it is either directly recursive or 
mutually recursive. Otherwise p is non-recursive. 



^ i.e. systems which provide a decision procedure for the problem: |= 3 c (where c is 
any constraint). 
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2.2 From CLP(x) to CLP{Bool) 

An approximatio^^A'^ from x to '0 consists in a pair of functions (Ask, Asm) 
with some properties (Ask deals with syntax and Asm with semantics; see Q 
for details). The main approximation we use is A® which turns CLP(x) objects 
into boolean objects and which is the composition of two approximations: 

1. A(^ : which, informally, replaces all data structures by their sizes (for example 
lists by their length, trees by the number of nodes, ...), 

2. Aff-. Ask(O) = 1, Ask(1) = 1, Ask(+) = A, Ask(>) ==>, Asm{n) = true. 

Intuitively, A%- is used to detect bounded variables. For instance, A^(4 > 
X + Y) = 1 ^ X AY which is equivalent toA=lAF=l. Hence, from the 
properties of A^, we conclude that X and Y are bounded in (4 > A + F). 

Example 2. Let C{x) = {E>^; {[ ], [-1-]}; {=}) be the lists structure over y, where 
as usual, the constant [ ] denotes the empty list and the operator [_|_] denotes the 
list constructor. We define the approximation A^^^^ from C{x) to Ask([ ]) = 
0, Asxi\x\y\) = 1 + Asxiy) and Asm([ei, . . . , e„]) = n. Let us approximate the 
well-known append CLP(£(x)) program: 



CLP(£(x)) version 


CLP(A^) version 


CLP(;B) version 


appQ J,Ys,Ys). 
app([X|Xs],Ys,[X|Zs]): - 
app(Xs, Ys, Zs). 


app(0, Ys, Ys). 
app(l + Xs, Ys, 1 + Zs) : — 
app(Xs, Ys, Zs). 


app(l,Ys,Ys). 
app(lAXs,Ys, lAZs) : - 
app(Xs, Ys, Zs). 



Now, we give some results related to approximations. Let A^ be an approx- 
imation, P be a CLP(x) program and its semantics Then, the image of 
the semantics of P is included in the semantics of the image of P\ 

Theorem 1. A(^(5^) C 

Here is a useful property about the boolean approximation A^: 

Proposition 1. (see B for details and examples) Let c\ be an J\f -eonstraint 
and t = y j(zj{Ai(zi.Xi) a boolean term. If A^{c\) t then 3j € J,Vz G Ij,Xi 
is bounded in ci . 

Moreover, we can compute the boolean model of a CLP(x) program and: 

Remark 1. Let P be a CLP(x) program. We can always assume that S^B(py 

the model of A®(P), contains exactly one formula p(i) Postp{x) for each 
predicate symbol p of P. 

We note Postp the boolean model of a predicate p because of the obvious 
link with the post condition of De Schreye and Decorte Q. 

^ An approximation is a simple way to present the abstract interpretation application 
in logic programs Q 
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Example 3. If we consider one more time the append program, then we have: 



Informally, it means that when a proof of a goal <— app{x, y, z) terminates 
in CLP(£(y)), on one hand the length of x is bounded and, on the other hand, 
the length of y is bounded if and only if the length of z is bounded. 

Remark 2. ^From now on, in the following sections, we consider only CLP(A/") 
programs and we denote by II the set of predicate symbols of a program. For 
any other structure, we switch to CLP(A/") by an appropriated approximation. 
For any numerical constraint c, we write c® its boolean version. 

3 Inferring left-termination conditions: 

The previous approach 

In Q for each predicate symbol p of a program P, a boolean term PrCp is 
computed. This boolean term is a condition of left-termination such that for any 
query <— c, p{x) if c® Prep{x) then the derivation of the query universally 
left-terminates. Let us summarize this result. 

Definition 1. A linear measure /ip for a predicate symbol p G p of arity n is a 
mapping defined by: 



s.t. Qi’s are integers (we note Ip^ the non empty set s.t. i G Ip^ implies 
Qi 0) and for each rule p{x) ^ c,B defining p, for each solution 9 of c, for 
each atom q{y) appearing in B with q G p we have: pLp{x9) > 1 -|- pLq{y9). 

Example 4- If we consider the CLP(A/’) version of append program then: 
y}{x,y,z) = x and y?{x,y,z) = z 
are two linear measures. 

The work of K. Sohn and A. Van Gelder shows that there exists a com- 
plete polynomial procedure for deciding the existence of a linear measure. This 
procedure can be adapted to compute the coefficients of /(. 

Definition 2. Let P be a CLP(J\f) program. Let p G p be a recursive predicate. 
Its set of maximal measures is always finite (see 0/ We write qp the number of 
maximal measures for a predicate p and Pp = {/i^ \p G p,l < j < qp} the set of 
associated maximal linear measures for p. Por each p G p, we compute a boolean 
term called its boolean measure defined by: 



Postappix, y,z) = X A{y ^ z). 




TN 

E TI 

i—l 



{xi, ...,Xn)^Y. 



lp{x) = V A 

l<i<9p ) 

If p is a non-recursive predicate, we set 7p(i) = 1. 
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The informal use of the term 7 is to give some information about potential 
decreasing of linear combinations of arguments of recursive predicates. 

Example 5. If we continue our example J we have p = {app}, Qapp = 2 and 
r-app = 3 .nd the boolean measure is -jappix, y, z) = x\J z. 

Definition 3. A boolean term Prep(x) is a left-termination condition for p(x) 
if, for every constraint c, c® — Prep{x) implies ^ c,p{x) left-terminates. 

Let P be a CLP(A/’) program, p a predicate symbol of P defined by rop rules. 
Let P® be the boolean version of P and the fcth-rule defining p in P® be: 

Theorem 2. Assume that for each predicate q ^ p appearing in the rules defin- 
ing p we have a left-termination condition Preq{y). If {Prep{x)}p^p verifies: 

{ Prcp{x) lp{x), 

VI < fc < mp,Vl <j< jk, 

(Prep(i) A cf_o ACi ^’ostp, Aifc.O) Prep,,^^{xk,j) 

then {Prep(5:)}pgp is a left-termination condition for p. 

Note that the above system of boolean formulae can be used not only to 
check that some relations PrCp’s are correct left-termination conditions but also 
to compute the PrCp’s by means of boolean /i-calculu J H. 

Let us explain the meaning of the formulae in the above theorem. The im- 
plication between PrCp and 7 p, forces the pre-condition to verify a minimal 
condition: entities that appear in the pre-condition have to be among the de- 
creasing ones. The second part says that when a rule such is used to prove an 
atom p{x), for each atom pkj appearing in the body, its calling context has to 
be sufficient to ensure its pre-condition. This calling context is the conjunction 
of the initial constraint of the rule and of course the post-conditions of all atoms 
placed (and thus proved) before pkj- 

Example 6. Let us consider the CLP(A/”) program, power-4, of the introduction. 
We compute: ^s{x, y) = x\Jy, Postg{x, y) = xAy, 7 p(a;, y) = 1 and Postp{x, y) = 
X Ay. For left-termination we find by the above method: PrCsix, y) = xV y and 
PrCp{x, y) = X. Informally, these relations give us the following informations: 

— for predicate s: for any query <— c,s{x,y), if a; or y is bounded in c, then 
the considered query left-terminates (PrCs) and after the proof x and y are 
bounded (Posts). 

— for predicate p: <— c,p(x, y), if x is bounded in c, then the considered query 
left-terminates and after the proof x and y are bounded. 

But as we said in the introduction, a query ^ c,p(x, y) s.t. y is bounded in 
c terminates if we prove s(z, y) before s(a;, z) and then, for the predicate p, we 
would like to infer Prcp(x, y) = x V y. 

® A boolean /i-calculus module for SICStus Prolog is available at our URL address. 



Inferring and Compiling Termination for Constraint Logic Programs 245 



4 Inferring extended left-termination conditions 

This section presents an important improvement of the previous method in order 
to infer larger termination conditions. The main idea consists in the introduction 
of the notion of order inside clauses. 

Definition 4. Let P be a CLP(Af) program and p be a predicate symbol of P. 
A boolean term Prep{x) is an extended left-termination condition for p{x) if for 
every constraint c, c® — Prep(x) implies that there exists a transformation of 
P and <— c,p{x), based on a renaminj^ of predicate symbols and a reordering 
of literals, such that the renamed goal <— c,p'{x) universally left-terminates with 
respect to the transformed program P' . 

The following definition presents the idea that allows us to deal with the 
notion of order inside clauses. 

Definition 5. Let P be a program. For each rule of P: p{x) ^ c, B where the 
body B contains the literals: pi, . . . ,pn (but we do not know the order of them), 
we can associate a sequence ofn{n— l)/2 boolean variables called 

order variables, with the following constraints (which express transitivity of the 
order relation): 



Property 1 . Let be a sequence of order variables associated to a 

set of predicate symbols pi,...,pn- This sequence defines a partial order over 
the predicate symbols and can be extended to a total order. We can represent 
this order by a permutation a over {1, . . . , n}. 

Example 1 . Let p\,pn and pz be three predicate symbols and 61^2, ^1,3, ^2,3 be a 
sequence of order variables such that 61,2 = 1 and 62,3 = 0. Then we have the 
partial order: pi before p2, Ps before p2, which leads to two possible total orders: 

— Pi,P3,P2 which corresponds to 5i_3 = 1 and the permutation a defined by 
(Ti = 1, (72 = 3 and (T3 = 2, 

— P3,Pi,P2 which corresponds to 61,3 = 0 and the permutation a defined by 
(Ti = 3, (72 = 1 and (73 = 2. 

^ Roughly speaking, the renaming specializes the logic definition of a predicate symbol 
p when p is used in different calling modes. 




The semantics of these variables is: 



yi<i<j<n, 



bij = 1 if Pi appears before pj 
= 0 if Pj appears before pi 
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And now we give the main result of the section. Let P be a CLP(A/”) program, 
p a predicate symbol of P defined by mp rules. Let P® be the boolean version 
of P and the fcth-rule Vk defining p in P® be: 



Theorem 3. Assume that for each q ^ p and appearing in the rules defining 
p, an extended left-termination condition Prcq has been computed. If the set of 
terms {Prcp}pgp verifies: 



\/p G p < 



Prep{x) 

VI < fc < mp ^(yi,h)^<e<h<jk VI < j < jk 
(Prep(i) A ^ ^ ACi V Postp^ fixk,i)) A 

i V Postp^ fixk.i))^ 



B Prep^j{xk,j) 



then {Prepipgp is an extended left-termination condition for p. 

Proof. This proof will be given conjointly with the proof of theorem^ 

Like theorem^ the system of boolean formulae of theoremHis actually used 
in our implementation to compute the terms PrCp (here again by a fixpoint 
calculus using boolean ^-calculus; some results are presented in a table in sec- 
tion^. The informal meaning is similar to the intuitive meaning of theorem ^ 
The only difference is in the second part. When we consider an atom pkj of the 
body, we do not know the atoms pk,i that appear before pkj and thus for each 
Pk,i‘ 

— either pkj appears before pk,i (i.e 6^^ = 0 or = 1, it depends whether 
i < j or i> j), 

— or pk,i is proved before pkj and in this case we add Postp^, 

In the rest of the paper we choose a convenient way to write pre-conditions: 

Definition 6. An extended left-termination condition can be written as a dis- 
junction of conjunctions of variables and in the following, we call class of queries 
such a conjunction (i.e. an extended left-termination condition is a disjunction 
of classes of queries). 



Example 8. Let us consider the following CLP(A/") program. The meaning of 
these relations is: s{x, y) iff y = p{x, y) y = x^ or x = y^ and q{x, y) iff 
X = y or X = y"^ or y = x'^. 

rule ri : s(0, 0). 

rule ra : s(X -b 1, Y -b 2 * X -b 1) :-s(X,Y). 

rule ra : p(X, Y) : - s(X, Y). 

rule T 4 : p(X,Y) : — s(Y,X). 

q(X,Y) : - p(X,Z), p(Z,Y). 



rule rs : 
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The only rule where an order can appear is rule r^. We assume that post/pre- 
conditions have been computed for predicate s and p: Pres{x,y) = x \/ y, 
Posts{x, y) = X A y, Prep{x, y) = x\/ y and Postp{x, y) = x A y. Let us remind 
what these informations mean: Pre.s says that any proof of a goal <— c, s{x, y) 
left-terminates if either a; or y is bounded in c and Posts adds that at the end of 
such a proof x and y are bounded (idem for p). To compute the PrCq condition, 
we solve the formula (since there is only one order variable in the formula, we 
write it b instead of 61 , 2 ): 



The condition found is: Preq{x, y) = xV y. And finally, for each predicate we 
can summarize its classes of queries; for s: Cl(x,y) = x and Cg(x, y) = y, for p: 
Cl(x, y)=x and Cl{x, y) = y and for q\ C^ix, y) = x and C^^x, y) = y. 

5 Reordering to left-terminate 

We did the first part of the work: compute for each predicate its extended left- 
termination condition. Now, if the user gives a query or a class of queries that 
entails the extended left-termination condition of the corresponding predicate, 
we must compile the program to another one by reordering the literals to ensure 
left-termination of the proof of the query. Let us define a formalism that allows 
us to capture the information we have on the program. 

Definition 7. Let {1, . . . , n} be a set of natural numbers. A permutation a over 
{1, . . . , n} is a bijeetion from {1, . . . , n} to {1, . . . , n}. We note Oi the image of 
i by the permutation a. 

Definitions. We define an environment as a tuple (P, {Prep | p € II}, fi) 
where: 

— P is a CLP(JV ) program with II as the set of its predicate symbols, 

— PrCp = \/ Cp is the extended left-termination condition of the predicate p, 

— 4> is a function that maps a rule Vk : p ^ c,pk,i, ■ ■ ■ ,Pk,jk o,nd a class Cp to 
a permutation over {1 , . . ., Jfc}. 

Concretely, an environment is computed as follows: after inferring the pre- 
conditions PrCp for each predicate p (theorem^, our implementation generates 
a permutation for each class Cp of PrCp and for each rule r^ defining p. To this 
aim, it computes using a boolean solver a sequence {b^ k)i<e<h<jk of booleans 
s.t. the following formula is true: 




{Preq{x, y) A (5 V Postp{z, y))) PrCp{x, y) 
{Preq{x, y) A {^b V Postp{x, z))) PrCp{y, z) 
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We get a (partial) instantiation of order variables j’s that we turn into a 
total instantiation corresponding to a permutation a. We define Vk) = <J. 

At this point, we have an environment for the program P. The rest of the section 
presents a top-down method to compile the initial CLP(A/’) program. 

Before we give formal definitions and algorithms, we present the reordering 
on the example ^to help the intuition. 

Example 9. We consider the program of exampleH^nd the computed results: for 
each predicate we have its associated classes of queries. Suppose the user wants 
to prove the goal: <— {y < 10}, q{x,y). First we must create the permutations 
associated with each pair {classe,rule). Here only one rule is concerned: r^. 
Applying the method described above, we find a boolean b such that the following 
formula is true: 

f (Cg (x, y) A (5 V Postp{y, z))) Ercp(x, z) 

[ {Cg {x,y) /\ {^b V Postp{x, z))) PrCp{y, z) 

and a boolean b' s.t.: 

f y) A (6' V Postp{y, z))) PrCp{x, z) 

[ (Cq (a;, y) A (^6' V Postp{x, z))) PrCp{y, z) 

The values we find are: 6 = 1 (hence, in the body of r^, p{x, z) has to appear 
before p(z, y) for the class Cg{x, y)) and 6' = 0 (i.e. p{z, y) has to appear before 
p{x,z) for the class Cg{x,y)). Then the function (j) is generated: 4>{Cg,r5) = a 
and (p{Cg,r5) = t where a and r are the two permutations over {1,2} defined 
by o"! = 1, (72 = 2, Ti = 2 and T 2 = 1. 

Now we can begin to construct the new program (the reordered version of 
the original one) . The user’s goal belongs to the class of the predicate q and 
thus we apply the permutation (piC'^^r^) to reorder the body of the clause. At 
the same time we rename the head and finally we obtain a preliminary version 
of the first rule of the new program: 

rule : q2(X,Y) : - p(Z,Y), p(X,Z). 

Then we must deal with the predicates appearing in the body of r'^: the 
calling context of p{z,y) is y bounded and thus belongs to the class Cp. Then, 
we perform the following operations: 

— rename p{Z, Y) by p'^{Z, Y), 

— recall recursively the method with the class of queries “y bounded, p{z, y)” . 

After these operations the new program is: 



rule : 


si(0,0). 


rule r '2 : 


s^(X -b 1, Y-b 2 * X-b 1) :-s^(X,Y) 


rule Tg : 


p2(X,Y) :-si(X,Y). 


rule T 4 : 


p2(X,Y) :-si(Y,X). 


rule Tj : 


q=(X,Y) : - p=(Z,Y), p(X,Z). 
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The literal p{x, z) remains to be processed. The calling context of p{x, z) is 
again z bounded since at the end of the proof of p{z, y) we have z and y bounded 
(information from Postp). The final version of the program is: 



rule : 


si(0,0). 


rule r '2 : 


s^(X + 1, Y+ 2 * X+ 1) :-s^(X,Y) 


rule Tg : 


p2(X,Y) :-si(X,Y). 


rule T 4 : 


p2(X,Y) :-si(Y,X). 


rule Tj : 


q=(X,Y) : - p=(Z,Y), p=(X,Z).< 



In the following, we present more precisely the method to rename and reorder 
a program. The renaming is realized by a table: 

Definition 9. Let {P,{Prep \ p S II}, 4>) be an environment. We define a re- 
naming table T as a mapping that associates an unique new symbol of predicate 
p^ to a pair {p, Cp) where p € II and Cp is a class of the extended left-termination 
condition of p. 

Hypothesis - Let us give the hypothesis for the reordering algorithm (un- 
formally presented in the example^ and the two properties^and^ We have a 
program P, {P, {PrCp \ p G II}, 4>) its computed environment, T the associated 
renaming table and <— c,p{x) a user query related to P s.t. (the boolean 
version of c) verifies: 3Cp € PrCp, c® — Cp. 

The three points below summarizes the method described by the algorithm 
given in the appendix at the end of this paper: 

1. we have a current goal <— c, q{x) (at the beginning, it is the user’s goal); we 
compute C the class of queries corresponding to the current predicate q with 
its current calling context c, 

2. we copy each rule r defining q in P, we rename q by the new symbol q', 
where q' = T{C, q) and we use the permutation <f>{r, C) to reorder literals of 
the bodies of the copied rules. Then we add these new rules in program P' , 

3. for each rule of P' , for each predicate p appearing in this rule but not defined 
in P' , we compute its calling context d. So we have a new current goal: 
<— d,p{y) and we apply the points 1 and 2 seen above. And so on. The 
procedure ends when all predicates appearing in P' are defined in P'. 

The new program P' verifies the two properties: 

Proposition 2. For allp' G W there exists p G II and C G Prep s.t. {p, C,p') G 

T . If we rename each symbol p' by its corresponding symbol p then we have: 
qP _ qP 

O pi — ’ 

Proof. The following actions do not affect the semantic of a program: duplicating 
a clause, reordering literals inside the body of a clause. 

Theorem 4. The proof of the query <— c,p'{x) universally left-terminates with 
respect to P' . 
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Proof. We can prove that each predicate p' of the new program P' and the 
corresponding term Prep> (the renamed version of PrCp) verify the hypothesis 
of theorem 5 Then we use this result to conclude. 

Let p' be a predicate symbol of P' and r' one of the rules defining p' in its 
boolean version: 

p'{x) ^ . ..,p'^{xn) 

By construction we know that: 

1. p' is a renaming of a predicate symbol p of P, 

2. the rule r' has been constructed from a rule r (from the boolean version of 

py. 

p{x) ^ c®,pi(ii), . . ,,p„(i„) 

defining p in P, a class of queries Cp of p and the corresponding permutation 

3. each predicate symbol p' , in the body of r' is a renaming of a predicate 

symbol pj in the body of r: V/ S n}, 3!j € n} s.t. p', is a 

renaming of pj . 

To apply the result of theorem ^ we must verify that the following system 
of implications holds: 

{ Prepi{x) lp'{x), 

VI <f<n (^Prep>{x) A c® A /\l,Zl{Postp,^^ (Si'))) 

Prep, (xp) 

3 

Let f G {1, . . . , n} and j be the unique index in {1, . . . , n} such that p'/ 
is a renaming of pj . By hypothesis of theorem Q we know that there exists 
{be,h)i<e<h<n & Sequence of order variables s.t.: 

{ Pr€p{x) lp{x), 

(^Prepix) A c® A V Postp^Xi)) A 

Ai=j + l{bj,i V Postp.{Xi))^ >B PxCp^ (Xj) 

Since we have (modulo the renaming): PrCp = PrCp, and 7 p = 7 p/, the first 
implication of (SI) holds. Since PrCp^Xj) = Prep ^Xj') (modulo the renaming), 

to achieve the proof we must show that: 

i'-i 

Prep{x) A c® A /y {Postp^ (Si')) 

i' = l 

implies 

j-l n 

Prep{x) A /\ l\^{^bij W Postp.(xi)) A {bpi\J Postp^Xi)) 

Let i < j and i' the unique index in {1, . . . , n} such that p(, is a renaming of 
Pi- We have two cases: 
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1. i' < f: p'/ is a renaming of pi thus Ai'=i (ij/)) implies Postp^{xi) 

and thus implies the conjunction Ai=i Postp^{xi)), 

2. i' > f: it means that the transformation from r to r' has changed the order 
between pi and pj. Inside r', p', appears after p', i.e. bij = 0 thus = 1- 

Here again, Ai'=i Ati(^A,j V Postp-{xi)). 

We deal with the second part of the conjunction (Ar=j+i(^i>* ^ Postp^(xi))) 
in a similar way. So, we know that (SI) is true and can conclude that Prep> 
is a left-termination condition for p' and thus the proof of the considered goal 
universally left-terminates. □ 

Proof (of the Theorem^^. Let us remind that to prove this theorem, we had 
to exhibit a transformation of P based on renaming and reordering operations 
such that the new program ensures the universal left-termination property. The 
previous proof has just shown that the transformation performed by our method 
verifies this condition. □ 

We end this paper by the example of the introduction. 

Example 10. When we apply our method on the program power-4 (examples | 
andH. We find: Pres{x,y) = xM y, Pr€p{x,y) = a; V y, (f){r^^x) = u (defined 
by = 1, W 2 = 2), (/)(r 3 , y) = J {uj[ = 2, = 1). 

Now let us consider the query of the introduction: *— y < 16, p{x,y). It 
corresponds to the class “y boundeP i.e. y = 1 in the boolean version. The new 
program P' is: 

rule A : p'(X,Y) : - s'(Z, Y), s'(X, Z). 

rule A : s'(0,0). 

rule A : s'(X -|- 1, Y -1- 2X -b 1) :-s'(X,Y). 

The call <— y < 16,p'(a;,y) left-terminates with answers: {a; = 0},{a: = 
!},{a:=2}. 

6 Conclusion 

Let us first summarize our approach. From our previous work on the inference of 
left-terminating classes of queries, we are able to get rid of any particular order 
of literals to compute the set of terminating classes of queries. The main idea is 
to encode all the orderings by introducing sequences of new boolean variables. 
Then, for any terminating class, we can statically compile the control into Prolog. 
In other words, we can produce a Prolog program such that for any query of this 
class, universal left-termination is guaranteed. 

The approach described in Q is now completely implemented. For the work 
presented here, we have implemented the computation of extended pre-condi- 
tions {Prepipgp as defined in section^ In the Table J we present some results 
on program tests found in N. Lindenstrauss et Y. Sagiv’s work^(times are given 



® in the full version of Q available at: http://www.cs.huji.ac.il/~naomil. 
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Table 1. comparison with Linderstrauss & Sagiv method 



Name of 




Hoarau/Mesnard 


program 


main predicate 


inferred classes 


time 


append 


append{x, y, z) 


|r V z\ 


0,47 


reverse 


reverse{x, y, z) 


{(r A i/) V (r A a) V (y A z)} 


0,89 


permute 


permute{x, y) 


{x\Jy} 


1,31 


hanoiapp 


hanoi{w, x, y, z,t) 


{(ui A r A j/ A a) V t} 


53,2 


f ib_t 




{r} 


7,3 


occur 


occurall{x, y, z) 


{x f\y} 


4,2 


money 


money{a, b, c, d, e, /, g, h) 


{1} 


3,65 


zebra 


zebra{a, b, c, d, e, f, g) 


{1} 


3,26 


Machine: Ultra 1 SUN Station, 128MB 


Name of 




Lindenstrauss / Sagiv 


program 


main predicate 


checked classes 


time 


append 


append{x, y, z) 


{x V z\ 


0,51 


reverse 


reverse{x, y, z) 


{x A z} 


0,17 


permute 


permute{x, y) 


{x} 


0,69 


hanoiapp 


hanoi{w, x, y, z,t) 


{w A. X Ay /\ z} 


62,5 


f ib_t 




{x} 


0,79 


occur 


occurall{x, y, z) 


{x Ay} 


2,45 


money 


money(a, b, c, d, e, /, g, h) 


{1} 


27,5 


zebra 


zebra{a, b,c,d,e,f,g) 


{1} 


0,58 


Machine: Super SPARC 51, 128MB 



in seconds). Concerning the reordering, a beta version of the implementation ac- 
cepts only CLP(A/") programs (with a time complexity insignificant with respect 
to the total time complexity). 

Let us point out that in all cases the set of classes of queries that we infer 
is at least as large as the set of classes checked by Lindenstrauss et Sagiv (see 
also B). We cannot expect the timings given by ^ or but we address a 
much more general problem. Note also that there is room for trying to optimize 
the control for a given logic: in the construction of an environment (section^, 
among the orderings which ensure termination, we may choose an ordering which 
leads to a “small” search tree. This is work in progress. 
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Appendix - The reordering algorithm 

Procedure: reorder 

Input: a program P, its environment E = {P,{Prep \ p € II}, 4 >), a renaming table 
T, a pair {p, Cp), s.t. p £ II, Cp a class of queries of PrCp. 

Output: a new program P' and U' its set of predicate symbols. 

Function: reorder_aux(p: a predicate, C a class of queries of p): R a set of rules 
Begin 
R^%-, 

let p' be s.t. {p,C,p') £ T; 

n'^n'u{p'}-, 

for all rule r : p(x) ^ c,pi(xi), . . . ,p„{x„) £ P do 
a «- (f){r, C); 

R^ RU {p{x) ^ c,pa^ (®<Ti), • • • ,P<T„(x<T„)}; 

end for 
return R-, 

End 

Main: 

Begin 

n' ^ P' <— reorder _aux(p, Cp); 

while 3 a rule Vk in P' s.t. a predicate in the body does not appear in II' do 
let Tk ■■ q°‘(y) ^ Cc,0,<7c.,l(ya,l), . . ■ ,qa.,j^{Va.,jJ) £ P'\ 
let C“ be the class of queries s.t. {q, Cq , q°‘) £ T; 

for i = 1 to ja do 
if qa,i £ n then 

let C^ be a class of queries of PrCq^ ^ s.t. 

Cq (y) A Ca,0 Aj = l C^(ya,i)’, 

let gf . s.t.{qa,i,C>^,q^i) £ T; 

P' ^’P'\{rk}-, 

P ^ P u {g {y) ^ Ca,0, qa,l{ya,l), • • • , q^ iiya,i), • • • , qajaiyaja)}’, 

if lt,i ^ n' then 

P' ^ P'U reorder_aux(gc,i, C^); 

end if 
end if 
end for 
end while 
return {P' , 77'); 

End 
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Abstract. It has become popular to express dataflow analyses in log- 
ical form. In this paper we investigate a new approach to the analysis 
of functional programs, based on synthesis of constraint logic programs. 
We sketch how the language Toupie, originally designed with logic pro- 
gram analysis as one objective, lends itself also to sophisticated strict- 
ness analysis. Strictness analysis is straightforward in the simplest case, 
that of analysing a first-order functional language using just two strict- 
ness values, namely divergence and “don’t know”. Mycroft’s classical 
translation immediately yields perfectly valid Boolean constraint logic 
programs, which, when run, provide the desired strictness information. 
However, more sophisticated analysis requires more complex domains of 
strictness values. We recast Wadler’s classical analysis over a 2n-point 
domain as finite-domain constraint solving. This approach has several 
advantages. First, the translation is relatively simple. We translate a re- 
cursive function definition into one or two constraint program clauses, in 
a manner which naturally extends Mycroft’s translation for the 2-point 
case, where the classical approach translate the definition of an n-place 
function over lists into 4’^ mutually recursive equations. Second, the re- 
sulting program produces relational information, allowing for example 
to ask which combinations of properties of input will produce a given 
output. Third, the approach allows us to leverage from established tech- 
nology, for solving hnite-domain constraints, as well as for hnding hxed 
points. Finally, the use of (disjunctive) constraints can yield a higher 
precision in the analysis of some programs. 



1 Introduction 

Strictness is an important concept in the efficient implementation of lazy func- 
tional programming languages. To improve generated code, compilers for such 
languages usually perform some sort of strictness analysis, trying to establish 
cases where relatively expensive call-by-name evaluation can be replaced by 
simpler call-by-value evaluation, without changing the program’s behaviour. A 
seminal study of strictness analysis was done by My croft Q, who suggested 
that analysis can be viewed as abstract interpretation. Mycroft considered first- 
order programs and gave an appealing translation method for such programs; 
his strictness analysis consists of translating the given program into a functional 
program that manipulates only Boolean values. Running the resulting program 
yields strictness information about the original program. 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 255-^^1999. 

(c) Springer-Verlag Berlin Heidelberg 1999 
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Strictness analysis was subsequently extended in two directions, to handle 
higher-order programs, and to deal with more complex strictness information. 
More complex strictness information is usually needed in the context of lists 
and user-defined data types. For example, the termination properties of a list- 
processing function may depend on the “shape” of the argument only, as is the 
case with the function length, which terminates if and only if the input list is 
finite, independently of the termination properties of the list’s elements. Seman- 
tically, the more complex information can be modelled by “non- flat” domains. 
Considerable progress was made when Wadler proposed a precise strictness 
analysis based on case analysis over a domain of four (or in fact a family of 
domains with 2n, n > 1) strictness values. The four-element domain i| 

T g Any list 

I 

Tg Any infinite list, and any finite list, some member of which is T 

I 

00 Any infinite list, and any list whose tail is T 

I 

T The undefined list 

There is no simple equivalent of Mycroft’s translation in the non-flat case. This 
is not only due to the fact that strictness properties no longer form a two- valued 
Boolean domain. As Wadler points out, reasoning by enumeration of cases seems 
necessary in the non-flat case and this would not be captured in a Mycroft-style 
translation where functions are approximated by functions. For example, we 
generally have that {head Tg) = T, where T is the top element of the usual 
two-valued strictness domain, 2 , that is, T stands for any value, defined or 
not. We also have that {tail Tg) = Tg, since Tg may represent, say, the list 
[T,2]. However, these simple mappings do not tell the full story. For example, 
if {head Tg) is known to be defined, that is, not to be T, then {tail Tg) must 
be Tg. Such interrelations among dependent sub-expressions are lost in a naive 
translation. 

We are interested in the use of constraint programming languages for pro- 
gram analysis, and one contribution of this paper is to show that a translation 
scheme for strictness analysis over a non-flat domain is not only possible, but 
also natural, if we work in a finite-domain constraint programming language. 
Dependent sub-expressions can then be handled via the introduction of “linking 
variables” (logic variables) and their subsequent removal can be performed via 
existential quantification. This translation has advantages: 

— It is easy to understand and quite general. 

— The need to tabulate abstract functions exhaustively disappears. 

^ Wadler’s original paper describes the meaning of the four elements slightly dif- 
ferently; we consider each element a subset of any element above it, as is common 
in the literature, see for example Plasmeijer and van Eekelen Section 7.6. 
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— The generated program can be run “forwards” or “backwards”, so as to 
answer questions about what output results from what input, with either 
(or none) constrained to particular values. 

— Sophisticated fixed point and constraint solving technology promises to make 
analysis fast. 

— The use of constraints allows for more precise analysis. 

We have implemented a strictness analysis method for a simple functional pro- 
gramming language with lists and pattern matching. The constraint language 
we use is Toupie []]. Toupie can be considered a finite-domain ^-calculus in- 
terpreter which allows fixed point problems to be stated succinctly and solved 
efficiently. It was originally designed for the abstract interpretation of logic pro- 
grams. However, it would seem that finite-domain constraint solvers would be of 
great help for a variety of static analyses used in the compilation and transfor- 
mation of functional programs, and a uniform approach to several such analyses, 
for example usage analysis and binding-time analysis, seems perfectly possible. 

We shall assume that the reader has some familiarity with functional pro- 
gramming and strictness analysis. Plasmeijer and van Eekelen ^ offer introduc- 
tions to both, as well as a discussion of Wadler’s method. 

In Sectionjwe outline classical strictness analysis via abstract interpretation 
and sketch the approach that uses constraint logic programming. Section^shows 
how we translate a functional program to a Toupie program that performs the 
strictness analysis. Section H briefly discusses the handling of other data types, 
and Sectionjconcludes. 

2 Strictness Analysis 

Consider the functional program 

power X n = if n=0 then 1 else x * (power x (n-1)); 

Following Mycroft | we can analyse this program for strictness by translating 
it to a recursively defined Boolean function: 

powef^{x,n) = nA true A {true\/ {x A power'^{x,n A true))). 

The idea is to translate termination behaviour into propositional logic, associat- 
ing truth with lack of information and falsehood with inevitable non-termination. 
Thus a constant such as 0 translates to true, since it would be wrong to claim 
that evaluation of 0 fails to terminate, while the comparison n=0 translates to 
n A true because ‘=’ is strict in both positions. So evaluation of the expression 
n=0 will terminate if and only if evaluation of n terminates. 

The conditional translates to a formula of the form c A (t V e) where c is the 
translation of the condition and t and e are the translations of the ‘then’ and 
‘else’ branches, respectively. Namely, evaluation of the conditional is guaranteed 
to diverge if the evaluation of the condition diverges or both of the branches 
diverge. 
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It is easy to see that we can simplify the right-hand side of the equation for 
power to get 

power'^{x, n) = n. 

Clearly then the evaluation of power fails to terminate if evaluation of its second 
argument does. So power is strict in position 2. 

In general, when solving recursive equations, we cannot rely on algebraic 
simplifications to make recursion “go away” , as happened above. We then resort 
to Kleene iteration. Consider the program 

gcd X y = if x=y then x 

else if x>y then gcd (x-y) y 
else gcd x (y-x) ; 

The corresponding strictness equation is 

gcdf{x, y)=xAyA{x\/{xAyA {gcdf{x A y, y) V gcdf{x, x A y)))) 

To find a closed form, we iterate from the initial guess gcd^{x, y) = false, even- 
tually reaching the fixed point gc(fl{x, y) = x A y. 

2.1 Wadler’s Method for Lists 

In the case of list-manipulating programs, we need more than two strictness 
values to get useful information. A list may be (partially) divergent, or some of its 
elements may diverge. The advantage of Wadler’s domain is that it allows us to 
identify cases where list-processing functions can safely evaluate their arguments 
using special evaluation mechanisms, such as element reduction, spine reduction, 
or reduction to head normal form 
Consider the program 

sum [] = 0 ; 

sum (x:xs) = x + sum xs; 

To translate the program into strictness equations, Wadler first determines that 
the best approximation to the list constructor ( : ) is as follows. For the possible 
values of x and xs, the value of (a; : xs) is: 



\XS 


J_ oo J_^ T ^ 


1 — 1 


00 00 Tg Tg 
00 00 Tg Tg 



This makes it possible to set up (and subsequently solve) four equations describ- 
ing the best approximation to sum, by a tedious but mechanical case analysis: 

sumfl" Tg = T U (T n {surir^ Tg)) 

sumr^ Tg = (T n {sumfl' Tg)) U (T □ {sumr^ J-g)) 

surrt^ (XJ = T n {sumfl" oo) 

surrt^ T = T 
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For example, the equation for sum^ Tg is generated by observing that the (list) 
argument T g would either have been [] or it would have been a composite list. 
In the former case, the right-hand side translates to ‘T’. In the latter case, the 
table for ( : ) shows that the list would have to be composed from prepending T 
to Tg, so the translation of ‘x + sum xs’ should be T □ {surrv^ Tg). The result 
is finally obtained by taking the join (maximum) of the two possible results. 
Solving the four recursive equations, we arrive at the solution 

ji f T if a:s = Tg 
surnT^ xs = < , , , 

( T otherwise. 

So the sum of a list is defined only if the list is finite and all of its elements are 
non-T, that is, they do not diverge. 

Note that with this method, the analysis of an n-place function requires the 
solution of up to 4" mutually recursive equations. 



2.2 A Constraint-Based Method 

We now sketch a solution which uses constraints and generates only one (albeit 
complex) recursive equation. First, it is convenient to use domains of integers 
to represent the strictness values (such as 2 = {1, 2} and 4 = {1, 2, 3, 4}), since 
then the constraint solver (Toupie) knows about the intended ordering of these 
values. Thus, instead of using Tg we use 3 (€ 4), and so on. Note that it is 
not necessary to treat strictness properties as integers in Toupie — indeed the 
language makes it easy to capture partially ordered sets of properties — but in 
our case integers and their linear ordering are convenient. For example, a join 
operation is simply taking the maximum of its operands. 

Here is how sum gets translated into a recursive constraint equation (the 
precise rules appear in Section 

surn^{xs,res) += (a:s = 1 A res = 1) 

V {xs = 4 A res = 2) 

V 3 hd, tl, red : 

res = min{hd, res') A sum^{tl, res') A cons'^{hd, tl, xs) 
cons'^{x,xs,res) = res = max{2,min{x + 2,xs)) 

The ‘-t- =’ indicates that we want the least solution to the recursive equation. 
(Toupie also allows to specify that a greatest fixed point is wanted.) 

The cons"^ rule captures the effect of list construction ( : ) . This clause is 
used every time a program involves list construction or list patterns. It expresses 
exactly the information present in the table in Section^H To rephrase the rule, 
the result {x : xs) in general is the least defined (the minimum) of the lists [x] 
and xs. For example, if a: is T (1) and xs is Tg (4) then [x] is Tg (3), and 
hence (x : xs) is Tg (3). In general, if x G 2 approximates some element h then 
X + 2 e 4 approximates [h\. However, (x : xs) does not diverge, even if x or xs 



260 



Tihomir Gabric, Kevin Glynn, and Harald S0ndergaard 



do. This explains the application of max which ensures that the result is at least 
oo (2). 

As we shall later see, the domains of variables may be other than 2 and 4, 
as nested lists may be described more precisely using higher domains n. The 
body of the cons"^ rule remains the same, but cons"^ may have different types 
of the form n x (n + 2) x (n + 2) — > Bool, for even n. Toupie needs to know the 
domains of variables, so a (simple) type analysis is necessary to establish these. 
In the rest of the paper we assume that programs have been decorated with type 
information. This is a reasonable assumption since the programming language 
is assumed to be typed and the analysis is only correct for well- typed programs. 

The example clearly shows how dependencies of sub-expressions can be cap- 
tured while the mechanics can be hidden through the use of existential quan- 
tification. The existentially quantified variables capture the dependencies. Their 
elimination is handled by Toupie. Their use render the kind of enumeration seen 
in Section^Junnecessary and allows us to express all variable dependencies in 
a single clause. In this sense the use of constraints generalises Mycroft’s method 
to non-flat domains in a natural way. 

The solution to the recursive equation for sum^ is also left to the constraint 
programming language. Notice that it is perfectly possible to obtain a closed form 
for sum^, by Kleene iteration and constraint solving. After the first iteration 
step (setting sum#(f/, res) = false) we get 

sum'^{xs, res) = {xs = 1 A res = 1) V (xs = 4 A res = 2) 

Using this approximation, the second iteration step adds 

3 hd : {res = 1 A cons'^{hd, 1, a;s)) V (res = min{hd, 2) A cons'^{hd, 4, a;s)) 
which simplifies to 

(res = 1 A a;s = 2) V (res = 1 A a;s = 3) V (res = 2 A a;s = 4) 

After this step, no more solutions are added. Indeed the Toupie solution comes 
out as 

{Xs=l, Res=l> 

{Xs=2, Res=l> 

{Xs=3, Res=l} 

{Xs=4, Res=2} 

in agreement with Wadler’s analysis. In SectionHwe argue that the constraint 
approach occasionally offers greater precision than Wadler’s approach. Another 
advantage of the constraint-based approach is that the analyser can be queried 
in different ways — for example, it makes sense for a compiler to ask, for a given 
function call, which input combinations make the call diverge. 

The programs that we generate are slightly more verbose than indicated by 
the example. Consider the following program: 
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fn_append(XO, XI, Result) += 
exist V0,V1,V2,V3 
( ( cr_nil(X0) 

& (Result = XI) 

) 

I ( exist EO 

( cr_cous (VI ,E0 .Result) 

& fu_appeud(V2,Xl,E0) 

) 

& cr_cous(Vl,V2,X0) 

) 

I ( dm_bot (Result) 

& dm_bot(X0) 

) 



Fig. 1. The Toupie code generated for analysis of append 



append [] ys = ys ; 

append (x:xs) ys = x : append xs ys; 

The Toupie translation of append is given in Figure J (Again notice that we 
produce one recursive equation to solve, rather than the 16 equations suggested 
by the traditional case analysis.) Some of the auxiliary predicates are domain 
dependent. In the current example, cr_nil(X0) translates to (XO = 4) because 
the domain is 4. The answers produced for the query fn_append(X,Y,Res)? are: 



{X=l, Y in 


1. .4, Res=l> 


{X=2, Y in 


1. .4, Res=2> 


{X=3, Y=l, 


Res=2} 


{X=3, Y=2, 


Res=2} 


{X=3, Y=3, 


Res=3} 


{X=3, Y=4, 


Res=3} 


{X=4, Y=l, 


Res=l} 


{X=4, Y=l, 


Res=2} 


{X=4, Y=2, 


Res=2} 


{X=4, Y=3, 


Res=3} 


{X=4, Y=4, 


Res=4} 


to 

1 

V 


displayed solutions 


2p -> OsOO 



In the last line of output, Toupie indicates the time spent on finding the solution, 
in this case negligible time. 
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Prog ::= {Def}* 

Def ::= Fname {Pat}* "=" Exp 

Pat ::= Integer 
I Var 
I 

I "(" PatList ")" 



PatList 



Pat 

Pat " : " PatList 



Exp : : = Exp Op Exp 
I Integer 
I Fname {Exp}* 

I 

I "(" Exp ")" 

I "if" Exp "then" Exp "else" Exp 
I Var 

Dp : := "+" I I ... 



Fig. 2. A simple functional language 

3 The Translation 

We now give the details of the functional language analysed, and the rules for 
translating programs into Toupie programs. The syntax of our language is given 
in Figure H It is a simple first order functional language with pattern matching 
on lists and integer constants. 

A natural approach when analysing a set of functions is to first divide them 
into so-called strongly connected components (SCCs), based on the program’s 
call graph. As a non-trivial example, FigureHshows the call graph of the revall 
program used in Section^ For example, revall calls both maprev and rev who 
in turn call other functions, possibly themselves. An SCC has the property that 
all functions within the SCC directly or indirectly call every other function in 
that SCC, but there is no mutual access between two functions in separate 
SCCs. In the example, each of the four functions forms its own SCC. The SCCs 
determine a stratification of the program, which is the natural order of analysis. 
In the example, we would analyse append first, then rev, then maprev, and 
finally revall. 

Figure B gives the algorithm used to translate functional programs into 
Toupie, and FigureHshows how expressions and patterns are translated. Note 
that patterns are translated using the same techniques as expressions. The result 
returned by a function is represented by a Result variable in a logic program- 
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revall 



maprev 




append 

L) 



Fig. 3. A call graph 



For each SCC S of the input program: 

For each function / defined in S do: 

Let k be the arity of /; 

Let Di, . . . , Dn be the n equations defining /, renamed apart 
so that vars(Di) n vars(Dj) = 0 whenever i 7 ^ j; 

For each i £ {1, . . . ,n\ do: 

Let[/pii ...pik=ei\ = Di 

Let V = vars{pqr : g G {1 . . . n}, r G {1 . . . fe}} 

Emit the two clauses: 

f{X^,...,Xk,R) += 

f**{Xi,...,Xk,R,true) 
f*{X^,...,Xk,R,T) += 

3 V : {T = true A (e'l V . . . V V (7? = _L A somepat(f)))) 
V (T = false A R = X A allpatff)) 

where 

e' = eicii R A £\pni Ai A ... A e\pik\ Xk 
somepat{f) = \J{Xq = X \ 3i : piq is not a variable} 
allpat^f) = /\{Xq = X \ 3i : piq is not a variable} 



Fig. 4. Translating function definitions 
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ein\R 

^IDI R 

£MR 
£l|eo (op) ei] R 
Sfeo ■■ ei] R 
£lf ei...efc] R 

£lf ei...efc] R 
f |if ei then 62 else 63] R 



(R^T) 

(7? = Tg) 

(R = v) 

3 Eo, El : f|eo] Eq A f|ei] Ei A R = min{Eo, E\) 

3 Eo,E\ ■. f [eo] Eq A il[ei] Ei A cons{Eo, Ei, R) 

3 Ei,...,Ek,Et f**{Ei, ...,Ek,R,Et) 

A ffei] Ki A ... A E\ek\ Ek, 

if / is in the current SCC 

3Ei,...,Ek-.f*{Ei,...,Ek,R) 

A f [ei] El A ... A £\ek\ Ek, otherwise 

3 El, E2 ,Es : 

(fleil El) A (f|e2l E 2 ) A (Elesj Es) A 
(((R = E2V R = E3)A {El = T)) 

V{{R = ±)A{Ei=±))) 



Fig. 5. Translating expressions into constraints 



ming style. The function £ takes an expression and a result variable name, and 
constructs a Toupie expression to constrain the result. For simplicity the rules as- 
sume that analysis of lists uses the 4-point domain, but this is easily generalised. 
In the next section we look at the handling of nested lists. 

There are two complications in the translation, and we address these in turn. 
First, the translation in Figure J must account for the use of (eager) pattern 
matching. During execution, if a function needs to compare some input value 
against a pattern, it must first reduce the value to weak head normal form Q. 
Only then is it able to make a meaningful comparison. However, if the input 
argument is T, this comparison does not terminate. The function somepat takes 
all the input patterns for a given function /, and for each argument position q, 
for which some clause has a proper pattern pig (not a variable), it generates the 
equation Xg = T. It then forms the disjunction somepat(f) of all such equations. 
The aim is to allow any solution 

Xg = EAR = 1. 

since a pattern-matched argument in position q may fail to terminate, and then 
the function which is being defined by pattern matching also fails to terminate. 
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The other complication is that an analysis must return a result, that is, a 
Toupie clause should not be allowed to fail. The natural translation of a function 
definition 

f Pil • • -Pik — 

is the clause 



f{Xi, . . . , Xfc, i?) -h= 3 V : e'l V . . . V e'„ V (i? = T A somepat{f)) 

where e' = S\ei\ R A f |piil A ... A £i|pifc] Xk- However, this will not be 
correct when a recursively defined function / has no base case and does not use 
pattern matching (so somepat(f) is false). 

Consider the function inf defined by 

inf X = X : inf x; 



The translation 

fn_inf (XO (Result) += 
exist EO 

( cr_cons(X0,E0, Result) 

& fn_inf (X0,E0) 

) 

is not correct, since queries to fn_inf will fail. 

The solution is to use an auxiliary function which ensures that fixed 
point iteration is started off at a point higher than false. The starting point 
for fixed point iteration is a constraint allpat(f) which is satisfiable and will 
not exclude any of the solutions that are due to pattern matching. Functions 
are given an additional parameter T. This is a tag which indicates whether a 
solution is a bona fide solution (T = true) or whether its purpose is to start fixed 
point iteration. For the vast majority of functions, the use of this is unnecessary, 
and in most cases the Toupie clauses can be simplified considerably. However, 
the more complex definition is needed for every function that may call itself 
recursively and does not have a non-recursive base case. 

For the function inf, the correct translation is: 

fn_inf (XO (Result) += 

f n_inf 1 (XO (Result ( 2) 

fn_infl(X0( Result (Tag) += 

( ( exist E0(E1 

( cr_cons(XO(EO(Result) 

& fn_infl(X0(E0(El) 

) 

& (Tag = 2) 

) 

I ( (Tag = 1) 
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Let k = the arity of /; 

Let Di, . . . , Dn be the n equations defining /, renamed apart so that 
vars{Di) n vars{Dj) = 0 whenever i ^ j\ 

For each i G {1, . . . , n} do: 

Let|/pii ...pik = ei\ = Di 

Let V = vars{pqr : g G {1 . . . n}, r G {1 . . . fc}} 

Emit the clause: 

, Xk, R) += 3 K : e'l V . . . V V (f? = -L A somepat{f)) 

where 

e' = Sleij R A f [Pill -^1 A • • • A Xk 



Fig. 6. Simpler translation of function definitions 



& (Result = 1) 

) 

) 

The result of querying the resulting Toupie program fn_inf (X,Res)? yields 

{X=l, Res=2> 

{X=2, Res=2> 

2p -> 2 displayed solutions 

2p -> OsOO 

That is, every x is mapped to the result oo, an infinite list. 

There are several ways the generated Toupie programs can be simplified. 
Many of the generated existentially quantified variables can be removed in a 
post-processing step. The pattern 3V : . . . f\V = X /\ ... is common in the 
automatically generated programs, and V is easily eliminated by replacing every 
occurrence of K by X. 

As discussed, if the definition of a function / has a base case, then R = 
T A somepat{f) is already a valid result, and there is no need to ensure that 
Toupie cannot fail. In this case the simpler translation given in FigureHsufRces. 

4 Other Data Types 

The translation extends easily to handle cases with nested lists, using ideas 
from Wadler For example, lists of lists are approximated by the six-element 
domain 6: 
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Tee 

I 

Tee 

I 

CX)g 



Te 

I 

oo 

I 

_L 

Here _L and oo have the same meaning as before, while an element of the form 
dg G 6 corresponds to a list, some member of which is described by d G 4. For 
example, [[1, _L, 3]] is approximated by _Lgg but not by oog. 

An initial type analysis determines the domains for the various variables. 
Consider the following program which uses append from before: 

revall xss = rev (maprev xss) ; 
maprev [] = [] ; 

maprev (x:xs) = rev x : maprev xs; 
rev [] = [] ; 

rev (x:xs) = append (rev xs) (x:[]); 

The generated Toupie clauses are shown in Figure H In this case the list vari- 
ables are in 6. Notice that cons need not be redefined — it was defined in such a 
way that it extends gracefully. The output from asking the most general query 
revall (X, Res)? is shown below, both as output from Toupie and in tabular 
form. 



{X=l, Res=l> 

{X=2, Res=l> 

{X=3, Res=3> 

{X=4, Res=3> 

{X=5, Res=5> 

{X=6, Res=6} 

2p -> 6 displayed solutions 

2p -> 0s08 

Handling other free data types is not hard. In general we will not obtain a linearly 
ordered domain of abstractions, but the ordering relation can be programmed 
explicitly in the constraint programming language. 

Alternatively, the components of a user-defined data structure can be rep- 
resented by separate logic variables. For functions of several variables we have 



input 


output 


Tgg 


Tee 


Tee 


Tee 




Te 


Te 


Te 


cx: 


T 


T 


T 
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fn_revall (XO , Result) += 

( exist EO 

( fn_rev(E0, Result) 
& fu_maprev(XO ,E0) 

) 



fu_maprev(XO,Result) += 
exist VO, VI 
( ( cr_uil (Result) 

& cr_uil(X0) 

) 

I ( exist E0,E1 

( cr_cous (EO , El , Result) 
& fu_rev(V0,E0) 

& fu_maprev(Vl ,E1) 

) 

& cr_cous(V0,Vl,X0) 

) 

I ( dm_bot (Result) 

& dm_bot(X0) 

) 



fu_rev(X0, Result) += 
exist VO, VI 
( ( cr_uil (Result) 

& cr_uil(X0) 

) 

I ( exist E0,E1,E2 

( fu_appeud(EO , El , Result) 
& fu_rev(Vl ,E0) 

& ( cr_cous(V0,E2,El) 

& cr_uil(E2) 

) 

) 

& cr_cous(V0,Vl,X0) 

) 

I ( dm_bot (Result) 

& dm_bot(X0) 

) 



Fig. 7. Toupie clauses generated for the revall program 



seen how detailed information can be maintained about their interrelation. This 
principle can be extended to include the components of results that are compos- 
ite. 



5 Conclusion 

It has become popular to cast analyses for functional programs analysis in logical 
form. Examples are Jensen’s “strictness logic” (for example Q), and “usage 
logic” as developed by Wadler and by Wright and Baker-Finch — for an attempt 
to provide a unifying framework for these, see Wright | i i | . Another trend is the 
formulation of analyses as “constraint” problems, as in the case of binding-time 
analysis Q which uses a combination of Boolean and Herbrand constraints. In 
strictness analysis, Sekar and Ramakrishnan Q] have also embraced constraint 
solving techniques. These analysis methods have included the invention of some 
constraint system and its solver. It is natural to ask what constraint (logic) 
programming can offer, and whether some uniform approach can be developed. 

Much research on constraint-based analysis views the problem as one of in- 
ference of “constrained types” in some sense. A good candidate for a basis for 
this is Sulzmann, Odersky and Wehr’s HM(X) Q, which is a Hindley-Milner 
type system extended with additional constraint reasoning capabilities. The ‘X’ 
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refers to the constraint domain applied, so HM{X) is parametric with respect to 
constraint domains. 

As an alternative, we have here explored an approach based on abstract in- 
terpretation, in which we exploit available constraint programming technology 
for program analysis. We have developed a method for strictness analysis over 
non-flat domains, using a constraint programming language to express strictness 
properties of the program under analysis. This method reconciles Mycroft’s clas- 
sical two- valued approach with Wadler’s technique for the non-flat case, translat- 
ing a function definition into a single constraint program clause. This is prefer- 
able to the classical method of generating up to 4" recursive equations for an 
n-place function. Exhaustive tabulation of abstract functions is replaced by more 
compact constraints. Moreover, the generated program can be run “forwards” 
or “backwards” , so as to answer questions about what output results from what 
input, with either (or none) constrained to particular values. 

We have found that Toupie offers easy expression of the analysis problem and 
supports high-precision analysis. Toupie has a fixed point operator and uses an 
efficient algorithm for finding fixed points over finite domains. Corsini et al. | 
applied Toupie to the analysis of logic programs, notably for groundness depen- 
dency analysis. In that application, constraint variables belong to a two-element 
domain, and it has been an interesting exercise to apply the same technology to 
a strictness analysis which uses domains of size greater than 2. 

The constraint programming approach gives much flexibility with respect to 
the granularity of information, partly because it naturally leads to disjunctive 
analysis, and partly because the components of composite data structures can 
be represented by separate logic variables. Usually, in the analysis of functions 
defined by cases, or using if-then-else, one takes the join, or least upper bound, 
of the results obtained for the individual cases or branches of computation. It 
is recognised that it would be more precise to tabulate all possible (combina- 
tions of) outcomes, but usually this is not feasible because of the large number 
of possible computation paths and the consequent efficiency penalty. However, 
(symbolic) constraints allow for a more compact representation of information. 
Note that we do not apply a least upper bound operation in the analysis given 
in this paper. 

Consider the program 

f X = if B then (x,17) else (17, x); 
g X = add (f x) ; 

Jensen | uses this example to show how disjunctive information translates into 
greater precision, even when the result of an analysis is not disjunctive. Assume 
the value of the Boolean expression B cannot be determined at analysis time. 
If we were to take the join of the two contributions from the branches of the 
conditional, we would end up with {x, true) U {true, x) = {true, true) as the 
result of analysing f . Based on this, the result for g would be true, that is, we 
would fail to recognise that g is strict. 

There have been other approaches to non-flat strictness analysis, such as 
projection analysis and PER analysis, see for example Cousot and Cousot Q. 
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It would be interesting to compare with these approaches. With constraints, 
complex interactions amongst both input and output components are naturally 
captured by the introduction of local “linking” variables that are subsequently 
eliminated through existential quantification. We feel that a method which uses 
these ideas, but also incorporates type inference, would be well worth developing 
and testing. 
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Abstract. We present a framework for automating the discovery of loop 
invariants based upon failed proof attempts. The discovery of suitable 
loop invariants represents a bottleneck for automatic verification of im- 
perative programs. Using the proof planning framework we reconstruct 
standard heuristics for developing invariants. We relate these heuristics 
to the analysis of failed proof attempts allowing us to discover invariants 
through a process of refinement. 



1 Introduction 

Loop invariants are a well understood technique for specifying the behaviour 
of programs involving loops. The discovery of suitable invariants, however, is a 
major bottleneck for automatic verification of imperative programs. Early re- 
search in this area exploited both theorem proving techniques as well as 

domain specific heuristics. However, the potential for interaction between these 
components was not fully exploited. The proof planning framework, in which we 
reconstruct the standard heuristics, couples the heuristic and theorem proving 
components tightly, allowing us to focus on both of these components together. 
In particular this enables us to exploit the relationship between failed proof 
attempts and invariant discovery. The framework described here builds upon 
previous work and shows how successive approximations are used to find a 
suitable invariant by a system automatically. This work was motivated by pre- 
vious work on discovering generalisations for inductive proofs. We exploit the 
relationship between while loops and tail recursive functions, but rather than 
transform our loop programs into tail recursive functions and discover a gener- 
alisation we choose instead to transfer heuristics across domains. This enables 
us to communicate proof attempts, and specifications in the same language. Ul- 
timately this will have significant benefits when integrating our approach within 
an interactive environment. 

The paper is structured as follows. In §2 we introduce background material 
where we focus upon proof planning and the rippling heuristic. §3 gives a proof 

* The contribution of the first author is supported by an EPSRC student ship award 
96307451, and the contribution of the second author is supported by EPSRC grant 
GR/L11724 
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plan for verification of loops. In §4 we show how the analysis of failed proof 
attempts can be used to guide the discovery of loop invariants. A detailed exam- 
ple, showing the refinement style of our approach, is presented in §5. §6 discusses 
results and implementation details. §7 discusses related work while future work 
is outlined in §8. Finally we draw our conclusions in §9. 



2 Background 

Hoare ^3 introduced his axiomatic proof rules for imperative programs 
involving loops in 1969. The aim was to assist the understanding of programs 
using rigorous logical techniques. The proof rules allow the transformation of a 
program, with suitable assertions, into a set of purely logical implications called 
verification conditions. These assertions are relationships between the program 
variables and program constant J Program constants are important since they 
are used to capture initial inputs to a program and are used in the post condition 
to relate a desired property in terms of these initial values. 

The verification of simple imperative programs involving loops falls short 
of full automation since Hoare’s rule for while loops involves synthesising an 
assertion known as the invariant. The while rule for partial correctness takes the 
form: 

P^J, {IAB}S{I}, 

{Pjwhile B begin S end {Q} 

The second premise is used to generate a verification condition using Hoare’s 
other proof rules. It is this verification condition which establishes I to be an 
invariant of the loop body S and is the focus of our work. 

The literature contains many heuristics for constructing invariants 

in a systematic way. These heuristics may weaken an initial guess, e.g. replacing 
a constant by a variable or term, or strengthen an guess, e.g. by introducing more 
conjuncts to the invariant. Previously, in we showed how proof planing was 
able to successfully discover tail invariants. Here this work is extended by adding 
heuristics to replace program constants and strengthen invariants. A general 
strategy is presented that enables the successive approximation of invariants 
using these heuristics. 



2.1 Proof Planning 

Proof planning Q consists of tactics, methods and critics. Tactics are rules 
of inference, either primitive or derived. Methods are partial specifications of 
tactics and allow the use of heuristics to focus their applicability. A method has 
preconditions and effects. Proof planning involves the search for a plan at the 
meta-level by using the methods and critics. A tactic is extracted from a plan 
and then run to ensure soundness. Critics ^3 are used to handle the failure of 

^ Program constants are denoted as calligraphic letters throughout e.g. X. 
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a proof attempt. They patch the failed proof attempt and provide a powerful 
mechanism for dealing with failure. 

The CLAM proof planner Q has been used, amongst other applications, for 
inductive proof Q. The success of the proof plan for induction is due to the 
ripple heuristic which is explained more fully below. 

Middle-out reasoning is a technique where meta terms are used to delay choice 
when planning a proof. The motivation is that the middle of a proof is typically 
more constrained than the start. Planning a proof from the middle-out therefore 
provides greater constraints than the conventional forwards or backwards style of 
proof construction. The implementation makes use of the higher-order features 
of A-prolog Bl’ Middle-out techniques have been used for generalisation 
logic program synthesis lemma discovery and induction revision Q. 

2.2 The Ripple Heuristic 

Rewriting often involves the manipulation of a goal formula so that a target 
formula can be applied. We are interested in proving theorems of the form: 

Hypothesis Conclusion 

where Hypothesis is the target formula and Conclusion is the goal formula we 
want to manipulate. Rippling is a difference reduction technique which exploits 
syntactic similarities between the goal and target in guiding the selective ap- 
plication of rewrite rules. In particular it identifies term structure within the 
goal which prevents a match with the target. For example consider the following 
implication: 

{x+ {y + z) = {x + y) + z) ^ (s(a;) + [y + z) = (s(a;) + y) + z) (1) 

The conclusion differs syntactically from the hypothesis in two places i.e. in 
the application of the successor function s around the two occurrences of x. We 
identify these differences with shading. Such term structures are called wave- 
fronts. Conversely any term structure within the goal which corresponds to the 
target is called skeleton. The parts of the skeleton inside a wave-front are called 
wave-holes. Wave-fronts, wave-holes and skeletons are meta-level notions. For 
the example above the conclusion is given the following meta-level annotation: 

(x -\- {y -\- z) = {x -\- y) -\- z) ^ s{x) -\- (y -\- z) = { s{x) -\- y) -\- z'^ 

Note that the wave-fronts are shaded. The skeleton of the conclusion is all the 
unshaded terms i.e. this corresponds to the hypothesis. An arrow is often used 
to indicate the direction in which a wave-front can be moved with respect to the 
skeleton term structure. Directed wave-fronts enable the termination of rippling 
to be guaranteed Q. For ease of presentation we have dropped the directions 
attached to the wave fronts since in this paper we will only be concerned with 
outward (|) directed wave-fronts. The movement of wave-fronts is performed by 
wave-rules, a syntactic class of rewrite rule which preserves skeleton while making 
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progress to eliminating wave-fronts. An algorithm exists which automatically 
generates wave-rules from all definitions and properties loaded into the system 
Q. For any equation there are usually a number of corresponding wave-rules. 
Consider the following recursive definition of plu^ : 



A-kO = 0 

s{A) + B = s{A + B) 

An example wave-rule derived from iQ i^ 

s(A) +B^ s{A + B) 



(2) 



(3) 



Notice that the skeleton on both sides of the wave-rules are the same, i.e. A + B. 
To use a wave-rule all the object-level and meta-level structure on the left hand 
side of the wave-rule must match with a sub-term of the goal formula. This sub- 
term is then replaced with right hand side of the wave-rule, taking into account 
any matching. We are able to reduce the differences between the hypothesis and 
conclusion in H, by successive applications of wave-rule B: 



{x + {y + z) = {x + y) + z) 
{x + {y + z) = {x + y) + z) 
{x+ {y + z) = {x + y) + z) 
{x+{y+ z) = {x + y) + z) 



Notice how the wave-fronts move to the top of the term structure. This meta- 
level structure helps to guide the search for a proof. Now we have a copy of part 
of our hypothesis in the wave-hole. Since our hypothesis is an equality we can 
use it to rewrite the goal. This we call (weak) fertilization and gives us the trivial 
goal: 




{x+ {y + z) = {x + y) + z) ^ (s((a; + y) + z) = s{{x + y) + z)) 

A stronger version of fertilization is applicable when a complete copy of the 
hypothesis appears within a wave-hole. 

2.3 Summary 

Rippling is a heuristic which supports the selective application of rewrite rules. 
This is achieved by firstly identifying the differences between two formulas. Sec- 
ondly, only using those rewrite rules which guarantee that the identical parts stay 

^ We use the Prolog notation of denoting first order variables with capital letters 
throughout. 

® Where denotes rewriting. 
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the same and thirdly, making sure that the differences are moved in a particular 
direction. Proofs guided by rippling can be classified in terms of the direction in 
which wave-fronts are moved with respect to the skeleton term structure. For a 
full account of rippling see The annotation described here can also be seen 
as embedding the target formula within the goal formula 

Identifying differences and constructing wave-rules is automatic. The real 
advantage of rippling over conventional rewriting techniques becomes apparent 
when rewriting in the presence of meta variables, as will be illustrated below. 



3 A Proof Plan for Verification 



expl: {x = XAy = y} 

r := 1; 

while (y > 0) do 
begin 

r -.= r * x\ 
y-y-1 

end 

{r = exp{X,y)} 

Fig. 1. Algorithm for computing exponentiation 



Consider the program in figure Q To verify this program we need a loop 
invariant. A suitable invariant is not immediately obvious and finding one is 
often referred to as a eureka step. One such invariant for this loop is: 

r = exp{X, y — y) Ax = X 

In order to verify that this property is indeed invariant involves proving the 
following verification condition generated by the loop body: 

(r = exp{X, y~ y)Ax = XAy^0) 

—* (r * X = exp(X, y — (y — 1)) A X = X) (4) 

The differences between the hypothesis and conclusion arise from the assignment 
statements in the loop body. To show that this is invariant we must rewrite the 
conclusion and move these differences up through the term structure until we 
are able to appeal to our hypothesis. Rippling provides us with the power to do 
this if we are able to annotate the conclusion with respect to the hypothesis. 
This suggests the following proof plan: 

Either a goal can be simplified or we annotate the conclusion with 
respect to the hypothesis then apply the wave method until we can 
fertilize with the hypothesis. 
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Inv_Strat 



Simplify 



Invariant 




Ripple 










Fertilize 









Fig. 2. Proof Plan for Verification 



The power of the proof plan is not that it can do the verification, but that it can 
be used to encode the heuristics we need to use in order to discover a suitable 
invariant from an initial guess. Figure H shows Inv_Strat, the proof plan we 
have developed for invariant verification. The component methods are shown in 
more detail in figures HOD Note that rippling consists of the repeated 

application of the the wave method, which is presented in figure H 



A Verification Proof 



Consider the following wave-rules: 



A- (B -C) 




{A-B) + C 




exp(A, 


B + 1 




exp{A, B) * A 




A*C = 


B * D 




A = B AC = 


D 



( 5 ) 

(6) 
( 7 ) 



Note that wave-rule Q is valid because we are reasoning in a goal directed 
style. Consider also the verification condition iQ above. In the proof of Q we 
are given 



r = exp{X, y~ y)Ax = XAy^0 
from which we must show the conclusion 



r * X = exp{X, y — {y — 1)) A X = X 
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Input sequent: 



h Gi A . . . A Gi A . . . A G„ 



Method preconditions: 



1. There exists a Gi such that Gi is unannotated (1 < i < n). 

2. And Gi follows from H trivially i.e. it is a tautology e.g. r = r or it follows from 
some simply data type property e.g. 0 7 ^ s( 0 ). 



Output sequent: 



77 h Gi A . . . A G„ 



Fig. 3. The Simplify Method 



Input sequent: 



77hGi[/i(...)]A...AG4/4...)] 



Method preconditions: 



1. Gi[/i(. . .)] A . . . A Gn[fn(. . •)] is unannotated. 

2. for all Gi[fi{. . .)] there exists a member Hj of 77 such that Gi[fi{. . .)] can be 
annotated with respect to Hj, e.g. 



Output sequent: 



Gi[/i(...) ]A...AG„[U{...) ] 



77hGi[ ]A...AGn[ /„(...) ] 



Sub Methods: 

Repeat wave then fertilize. 



Fig. 4. The Invariant Method 



Input sequent: 

77hG[/i( ci(...) )] 

Method preconditions: 

1. there exists a sub-term T of G which contains wave-front (s), e.g. 

/i(ci(...) ) 

2. there exists a wave-rule which matches T, e.g. 

G^/i(ci(X) C 2 (/i(X)) 

3. any condition G follows from the context, e.g. 

H\-G 



Output sequent: 



77hG[ C2(/i(...)) ] 



Fig. 5. The Wave Method 
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Input sequent: 



H[expi] h Gi A . . . A expi A . . . A Gn 

Method preconditions: 

1. There exists a hypothesis that matches with a conjunct in a wave hole in the 
conclusion, e.g. 

expi 



Output sequent: 



H[expi] h Gi A . . . A G„ 
Fig. 6. The Fertilize Method 



by the application of the Inv_Strat proof plan. The proof found by the proof 
planner is as presented below: 



r * X = exp{X, y — {y — 1)) Ax = X 
r * X = exp{X, y — {y — 1)) 



fr:* X I =exp{X,y- (y-l) ) 



Conclusion 
By Simplify 

By Invariant 



X I =exp{X, (3^ — y) + l ) By Wave using 

By Wave using 



X I = exp{X,y — y) *X 



r = exp{X, y — y) !\x = X 



x = X 
true 



By Wave using ^ 
By Fertilize 
By Simplify 



4 Analysis of Failure 

In this section first we review two standard heuristics for discovering loop in- 
variants from the literature namely replacing constants by terms and 

strengthening invariants. We formalise these heuristics within the proof planning 
framework as critics. 

The full benefits of the rippling heuristic become apparent when the proof 
attempt fails. By relating this failure to a standard heuristic for developing 
loop invariants, we are able to suggest a patch which will give a new candidate 
invariant. 
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4.1 Replacement of Constants 

A standard heuristic for developing loop invariants is replacing constants by 
terms containing program variables. The idea is that by replacing a constant 
with a term structure containing a program variable we increase the state space. 
Often it is only in this increased state space that the invariant relation can be 
established. To formalise this heuristic as a critic we need to relate it to the 
partial success of a proof method, namely the wave method. The wave method 
can fail because it fails to match the left hand side of a wave-rule with part of 
the goal. Wave-rule matching is defined as: 

Wave-rule Match: Given a goal T and the left hand side of a wave-rule L, 
then T and L match iff: 

— The object level term structures of L and T match. 

— For all wave-fronts in L there exists a matching wave-front in T. 

Constants can block a ripple because they can prevent a match between the 
left hand side of a wave-rule and a sub-term of the goal. This happens when 
at least one wave-front within a wave-rule is aligned with a term containing a 
constant in the goal. However, we can define a potential match which suggests 
we have the opportunity to match if we could introduce some difference i.e. 
wave-front, by replacing constants: 

Potential Match: Given a goal T and the left hand side of a wave-rule L, then 
T and L potentially match iff: 

— For all wave-fronts in L there exists either a matching wave-front in T 
or a term containing a constant. 

— The object level term structures of L and T match every where expect 
at the positions where a wave-front in L matches a term containing a 
constant. 

For example, attempting to match r *x = exp{X ,y) and the left hand side 
of the wave-rule 0: 

H = B *D 

would be a potential match because there is a term containing a constant on the 
right hand side of the equality in the sub-term, e.g. exp{X ^y), where the wave- 

rule has a wave, e.g. B * D . Note that all other meta-level and object-level 
term structures match. 

Having a potential match tells us that we need a wave-front where we have 
a term containing a constant. The replacement of constants heuristic tells us to 
replace a constant with a term containing a variable which has been assigned 
within the loop body. To coerce this wave-rule match we need to do two things. 
Firstly we need to decide which constant to replace, if there is more than one. 
Secondly we need to discover the replacement term. The first step is achieved 
by taking the mismatched wave-front in the wave-rule and pushing them back 
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towards the constants within the goal. This is achieved by applying the wave- 
rules backwards, with a schematic wave-front. For the potential match above we 
want to coerce exp{X,y) to be the wave . Since we are only replac- 

ing constants we know the skeleton must be exp{T\^T 2 ), where T\ and T 2 are 
either new terms or the constants in those positions. We start with the wave 

exp{Ti, T 2 ) * D and use wave-rule iQ backwards to get the term: 

exp{D, [^-1-1 ) 

We now have identified that the required wave-front needed can be generated by 
replacing the second argument of exp with a term containing a wave-front of the 
form . We could continue backwards to find the term we are looking 

for. However the search space is less controlled in this direction. We continue 
in a forwards direction by replacing the constant identified with a higher order 
meta-term. The arguments to the meta-term are the program variables assigned 
to in the body of the loop and the constant we have replaced. 

The constant replaced and all the variables assigned to in the body are used 
as arguments for the meta-term. This then gives rise to a new candidate invariant 
which we use with the expectation that rippling will instantiate the meta-term. 
The replacing constants by terms patch is given in more detail in figureH 



Blockage: 



Critic preconditions: 



H^G\g{ /i(...) 






— precondition 1 of the wave method sncceeds. 

— precondition 2 of wave method has the potential to succeed, i.e. 

1. There exists a sub-term T of G that contains wave-front(s). 

,/2(T,...)) 

2. There exists a wave-rule which has the potential to match with T 



g{ . / 3 (...) ) 



Patch specification: 

Coerce precondition 2 by replacing the blocking constant with a meta- variable e.g. 



f 2 {X, . . .) becomes f 2 {M {. .) 



Where M is a second-order meta-variable. 



Fig. 7. Patch: Replacing Constants by Terms 
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4.2 Strengthening invariants 

Gries ^ explains a simple, but powerful, heuristic for dealing with blocked proof 
obligations. The idea is to assume the very thing that we are trying to prove. 
This has the effect of instantly making the proof obligation trivial. However now 
we have to show that this proof obligation is itself invariant. To formalise this 
heuristic as a critic we observe that at the end of a ripple proof we are sometimes 
left with some proof residue. This is a sub-term that requires some further proof. 
This residue can sometimes be proved using the simplify method, but when it 
cannot, we have to start the invariant proof process again. The invariant method 
tries to annotate a subgoal. If we are unable to annotate it then we are blocked 
since we will not be able to ripple. 

Using this failure to annotate the differences between a subgoal and the 
hypotheses we can refine our candidate invariant using the heuristic above, he. 
the conclusion we are unable to annotate is added to our candidate invariant 
and we start the proof again. For example suppose a proof attempt fails on the 
goal: 

(r = exp{X, y~ y)t\y^G)^x = X 

The failure is due to the proof residue x = X which we can neither derive from 
the hypotheses nor annotate with respect to any particular hypothesis. The patch 
is to add x = X to the invariant candidate. Thus the new candidate invariant 
becomes: 

r = exp{X, y — y) Ax = X 

The strengthening invariant critic is given in more detail in figure J 



Blockage: 

H\-G 

Critic preconditions: 

— precondition 2 of invariant method fails, he. 

1. The conclnsion is unannotated. 

2. We cannot annotate G with respect to a member of H. 

Patch specification: 

Coerce precondition 2 by introducing those parts of G that we are unable to annotate 
in our candidate invariant. 



Fig. 8. Patch: Strengthening invariants 
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5 Refining Invariants 

In this section we briefly explain the overall strategy used to And invariants and 
thus construct proofs of loop programs. We then show this in action using an 
example. 

The above methods and critics have been encoded within the clam proof 
planning system, clam is allowed to exhaustively search before attempting to 
Are any critics. 

The replacement of constants and strengthening invariants critics together 
allow us to successively refine approximation to our invariant. The idea is to 
use the post condition as our initial guess and successively refine our invariant 
candidate. If we have proved that our new property is invariant we then have 
to show that it actually implies the post condition i.e. it is not too weak. For 
example, suppose we have shown 1 to be invariant over successive refinements 
of our post condition Q we have to show that (/ A ^ Q where B is the loop 
guard. 

Example 

For example, consider the program in figure l|, and the wave-rules Q, Q and 
Q introduced above. 



First Approximation (Post-condition): We take the post-condition: 

r = exp{X, 3^) 

as our first approximation to the invariant. This gives the verification condition: 

(r = exp{X, y)t\y^Q)^r*x = exp{X, 

This goal cannot be simplified so we apply the invariant method giving: 

(r = exp{X, y) /\y ^ 0) ^ r * x = exp{X, 3^) 

Now we are stuck. We are unable to apply any of the wave-rules. We are left 
resorting to using the critics to try and patch our goal. Firstly we notice that 
we have a potential match between the goal: 

r * X = exp{X , 3^) 

and the left hand side of the wave-rule Q: 

A B 

Secondly we decide which constant to replace. The right hand side of the wave- 
rule fl: 

exp{A,B) *A matches with exp{X,y) *D 
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the result of our potential match. Looking at the left hand side of this wave-rule 
we are able to determine that the difference came from the second argument of 
exp, so we replace the y with the meta term M\ (r, y, 3^) giving the new candidate 
invariant: 

r = exp{X,Mi{r, y,y)) 

Second Approximation (Result of replacement of constants critic): 

This new candidate invariant is used to set up a verification condition: 

(r = exp{X , Mi{r, y, 3^)) Ay^0)^r*x = exp{X, Mi{r * x,y — 1, 3^)) 

The proof attempt continues: 

r * X = exp{X , Mi{r,y,y)) Conclusion 





r ^ X 


= exp{X , Ml { r * X , y 


-1 ,3^)) 


By Invariant 


r ^ X 


= exp{X, (M 2 ( r*x , 


y - 1 


.y)-y) + l 


) By Wave using Q 










r ^ X 


= 


exp{X, M 2 { r * X , 


y - 1 


.y)-y) 


* A 


By Wave using Q 



r = exp{X, M 2 { r * X , y — I ,y) — y) Ax = X By Wave using Q 
X = X By Fertilize 



The first application of wave has the effect of finding an instantiation for Mi 
to be XX.XY.XZ. M 2 (A, Y, Z) — Y. The fertilization step instantiates the meta- 
variable M 2 to be a projection onto it’s third argument i.e. M 2 is instantiated 
to XX.XY.XZ. Z , so Ml becomes XX.XY.XZ.{Z - Y). 

Now we are stuck again, this proof obligation is not trivial and we are unable 
to annotate it. The strengthening critic now fires and generates a new candidate 
by including the proof residues, giving the next approximation: 

r = exp{X, y — y) Ax = X 



Third Approximation (Result of strengthening critic): Again we set up 
a verification condition: 



(r = exp{X, y~ y)Ax = XAy^Q)^{r*x = exp{X , y — {y — 1)) A x = X) 
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The proof now follows: 

r * X = exp{X, y — {y — 1)) t\ X = X 

r * X = exp{X, y — {y — 1)) 



1^* X I =exp{X,y- (y-l) ) 



Conclusion 
By Simplify 
By Invariant 



= exp{X, {y — y) + ^ ) By Wave using 

By Wave using 



X I = exp{X ,y — y) *X 



r = exp{X, y — y) Ax = X By Wave using 



a; = -T 



true 



By Fertilize 



By Simplify 



So we have shown that r = exp{X , y — y) Ax = X mi invariant to the loop 
body. To finish the proof we check that our invariant satisfies the first and third 
premises of the while rule. 



6 Results and Implementation 

Our work on invariant discovery has been implemented within the CLAM proof 
planner It describes a systematic framework for refining initial approxima- 
tions to a loop invariant automatically in a principled way. Initial results using 
examples from the literature are promising, and are summarised in table Q. 
We draw the readers attention to the more complex problems involving arrays, 
notably Cries’ minimum sum segment problem Q. Our approach is syntacti- 
cally driven and requires defining equations and properties needed to complete 
the proof. There is no restriction that these defining equations are recursive or 
the specification is immediately executable. In the exp example (see figure J, 
note that the definition of exp is constructive, while the imperative algorithm is 
destructive. 



7 Related Work 

Early research into Automatic Programming investigated heuristic based meth- 
ods for discovering loop invariants. Wegbreit Q developed an approach in which 
a candidate invariant was incrementally refined using both domain-independent 
and domain-specific heuristics. The choice of refinement was guided by the sat- 
isfiability and validity of the current candidate invariant. The theorem proving 
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Program 


Post Condition 


Invariant Discovered 


exp 


r = exp{X, y) 


r = exp{X, y — y) A X = X 


sum 


r = sum{X) 


r = sum{x) 


times 


r = x*y 


r = {X — x)*yAy = y 


factorial 


r = fac{X) 


r = fac{x) 


min-array 


m = min(0 <i<M\ a[i]) 


m = mm(0 < i < n : a[i]) 


sum-array 


AI r --I 


71 r .-1 

s = Ei = n “W 


min-sum-seg 


s = min {0 < i < j < Af 


s = mm(0 < i < j < n ■. a[i]) 

Ac = mm(0 <i<n\ a[i]) 



Program exp is given in figure (1). Programs sum and factorial compute the sum and 
factorial of the first X natural numbers respectively. The program times multiplies 
two natural numbers by successive addition. Programs min-array, sum-array and 
min-sum-seg find the least element of an array, the sum of an array and the minimum 
sum segment of an array respectively. 

Table 1. Invariant Discovery Results 



and heuristic components were only loosely coupled. This was reflected in other 
heuristic approaches at the time Q. Wegbreit hinted, however, that a closer 
relationship between the heuristic guidance and the theorem prover would be 
desirable. The proof planning framework in which our heuristics are expressed 
enables this close relationship to be achieved. 

Our approach, like all heuristic based techniques, is not complete. A complete 
approach has been designed Q based upon a novel unskolemization technique 
for deriving logical consequences of first-order formulae. Completeness, however, 
comes with a price. In practice this means that any inductive lemmas required 
for a particular verification task must be provided by hand. 

Our technique is very tightly coupled to the syntactic structure of the initial 
invariant. A more semantic approach to verification is described by Mili 
where program semantics are found independently of their specifications and 
heuristics are given for discovering invariant properties. One way of discovering 
these invariant properties is to use the strongest invariant function of a loop body 
However it is unclear how we would be able to automate the discovery of 
such functions in general. In this work the programs are described by relations of 
input sets to output sets. Bundy and Lombart Q have formalised the notion of 
relational rippling to reason with relations describing logic programs. The work 
on relational rippling may be relevant to Mill’s approach. 

Critics have been used in the context of inductive proof to discover 

generalisations, revise induction rule selection, perform case splits and discover 
missing lemmas. Previously in Q we showed how the work on generalisation 
for induction transfers to the domain of loop invariant verification. The critics 
reported here, however, have been developed directly from standard heuristics. 
So how do these critics relate to the inductive proof plan? 
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Program 


Critic used 


exp 


RC and S 


sum 


RC 


times 


RC and S 


factorial 


RC 


min-array 


RC 


sum-array 


RC 


min-sum-seg 


RC and S 



RC indicates the application of the replace constant critic and S indicates the applica- 
tion of the strengthening critic. 

Table 2. Critic Usage 



Firstly the replace constants by terms critic is very similar to the induction 
revision critic. This is not unsurprising as often we are replacing a constant by 
a local loop variable used to ensure termination z.e. an induction variable. This 
is reflected in the pattern of failure we observe in the ripple method. Both the 
replace constants by variables critic and the induction revision critic, achieve 
partial success with the second precondition of rippling, z.e. there is a wave-rule 
match. 

Secondly the failure pattern for the strengthening invariants critic corre- 
sponds to a complete failure to annotate the conclusion with respect to a hypoth- 
esis. It has been observed that a similar failure pattern occurs when reasoning 
about mutually recursive functions. 

8 Future Work 

Extensions to the above framework build upon the premise that the post-con- 
dition is a good starting point for developing an invariant through successive 
refinements. The critic mechanism will be used to refine this initial invariant 
based upon the partial success of our proof methods. The nature of the plan- 
ner’s methods allows a systematic analysis of failure. Future work will involve 
extending the system to deal with more complex examples including nested 
loops, branching constructs within loop bodies and array assignment. 

9 Conclusion 

The discovery of loop invariants represents a bottleneck within the automatic 
verification of imperative programs. Building upon the proof planning framework 
and proof critics in particular, we have shown that by the productive use of failed 
proof attempts we are able to automate the synthesis of suitable invariants. 

We believe that our success is due to the tight coupling between the heuristic 
and the theorem proving dimensions which proof planning facilitates. 
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Abstract. This paper presents several verification methods for logic 
programs with delay declarations. It is shown how type and instantiation 
errors related to built-ins can be prevented, and how termination can 
be ensured. Three features are distinctive of this work: it is assumed 
that predicates can be used in several modes; it is shown that block 
declarations, which are a very simple delay construct, are sufficient to 
ensure the desired properties; the selection rule is taken into account, 
assuming it to be the rule of most Prolog implementations. The methods 
can be used both to verify existing programs and to assist in writing new 
programs. 

1 Introduction 

Delay declarations are provided in logic programming languages to allow for more 
flexible control, as opposed to the left-to-right selection rule of Prolog. An atom 
in a query is selected for resolution only when its arguments are instantiated 
to a specified degree. This is essential to prevent run-time errors produced by 
built-in predicates (built-ins) and to ensure termination. 

We assume that delay declarations may be used to enable programs to run 
in multiple modes. Although other authors have not explicitly assumed 

multiple modes, they mainly give examples where delay declarations are clearly 
used for that purpose. However, our results are also useful in the context of other 
applications of delay declarations, such as the test-and-generate paradigm 
or parallel execution Q. 

Our contributions are: showing how type and instantiation errors related to 
built-ins can be prevented; showing when delay declarations for built-ins can be 
omitted completely; and showing how termination can be ensured. 

For all of the above, we demonstrate that under realistic assumptions, block 
declarations, which declare that certain arguments of an atom must be at least 
non-variable before that atom can be selected, are sufficient. As demonstrated in 
SICStus I, block declarations can be efficiently implemented; the instantiation 
test has hardly any impact on performance. Thus, in practice, such constructs 
are the most frequently used delay declarations. 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 289^B 
© Springer-Verlag Berlin Heidelberg 1999 
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For arithmetic built-ins, we exploit that for numbers, being non-variable im- 
plies being ground, and show how to prevent instantiation and type errors. Some- 
times, it is not even necessary to have any delay declarations at all for built-ins. 

Predicates which use their own output as input (circular modes) are a well- 
known source of loops which must be eliminated to ensure termination . We 
generalise the idea of “well-behaved” modes to multi-moded predicates. 

Another source of loops is speculative output bindings, that is bindings made 
before it is known that a solution exists We propose two methods for dealing 
with this problem and thus proving (or ensuring) termination. Which method 
must be applied depends on the program and on the mode being considered. 
The first method exploits that a program does not use any speculative bindings, 
by ensuring that no atom ever delays. The second method exploits that a pro- 
gram does not make any speculative bindings. We always reduce the problem 
to showing termination for programs without delay declarations, such that any 
method for programs without delay declarations can be applied. 

The approach to termination presented here is simple and formalises previous 
heuristics Although there are some clear limitations of the approach, it 

is not subsumed by any method we know of, in particular not by the method we 
presented in 

The rest of this paper is organised as follows. The next section gives some 
preliminaries. Sectionjdefines some concepts of modes and types which are the 
basis of our verification methods. Sectionjis about errors related to built-ins. 
Section^is about termination. Section^investigates related work, and Section^ 
concludes. 

2 Preliminaries 

We base the notation on For the examples we use SICStus notation Q. 

We recall some important notions. The set of variables in a syntactic object o is 
denoted by vars(o). A syntactic object is called linear if every variable occurs 
in it at most once. A flat term is a variable or a term of the form f(xi, . . . , a;„), 
where n > 0 and the Xi are distinct variables. The domain of a substitution a 
is dom(a) = {x \ xa ^ a;}. 

For a predicate p/n, a mode is an atom p(mi, . . . , m„), where rrii G {I, 0} 
for i G {1, . . .,n}. Positions with I are called input positions, and positions 
with O are called output positions of p. A mode of a program is a set 
containing one mode for each of its predicates! A program can have several 
modes, so whenever we refer to the input and output positions, this is always 
with respect to the particular mode which is clear from the context. To simplify 
the notation, an atom written as p(s,t) means: s and t are the vectors of terms 
filling the input and output positions of p, respectively. 

A type is a set of terms closed under instantiation. A non-variable type 
is a type that does not contain variables. The variable type is the type that 

^ This can easily be extended to allow for different occurrences of a predicate within 
a program to have different modes. 




Preventing Instantiation Errors and Loops for Logic Programs 291 



contains variables and hence, as it is instantiation closed, all terms. A constant 
type is a type that contains only (possibly infinitely many) constants. In the 
examples, we use the following types: any is the variable type, list the type of 
(nil-terminated) lists, num the type of numbers and nl the type of number lists. 

We write t : T for “t is in type T”. We use S, T to denote vectors of types, 
and write )= s : S ^ t : T if for all substitutions cr, scr : S implies ta : T. 
It is assumed that each argument position of each predicate p/n has a type 
associated with it. These types are indicated by writing the atom p{Ti , . . . , T^) 
where Ti, . . . , are types. The type of a program P is a set of such atoms, 
one for each predicate defined in P. 

A block declaration | for a predicate p/n is a (possibly empty) set of atoms 
each of which has the form p(6i, . . . , 6„) where bi G {?, -} for i G {1, . . . , n}. A 
program consists of a set of clauses and a set of block declarations, one for 
each predicate defined by the clauses. If P is a program, an atom p{ti , . . . , tn) 
is selectable in P if for each atom p(6i, . . . , 5„) in the block declaration for p, 
there is some i G {1, . . . , n} such that p is non- variable and bi = 

A query is a finite sequence of atoms. A derivation step for a program P 
is a pair (Q, 9); (P, 9cr), where Q = Qi,a,Q 2 and R = Q\, B, Q 2 are queries; 9 
is a substitution; a an atom; /i <— P a renamed variant of a clause in P and a 
the most general unifier of a9 and h. We call a (or a6*^ the selected atom and 
R9a the resolvent of Q9 and h ^ B. 

A derivation ^ for a program P is a sequence {Qo, 9 q); (Qi, 9i); . . . where 
each pair {Qi,9i)\ (Qi+i,6*i+i) in ^ is a derivation step. Alternatively, we also 
say that ^ is a derivation of P U {Qo9q}. We also denote ^ as Qo9q; Qi9i; . . .. 

An LD-derivation is a derivation where the selected atom is always the 
leftmost atom in a query. A delay-respecting derivation for a program P is 
a derivation where the selected atom is always selectable in P. A derivation is 
left-based if it is either an LD-derivation, or it contains at least one non-empty 
query where the leftmost atom is not selectable. To the best of our knowledge, 
derivations in most Prolog implementations are left-based. 



3 Permutations and Modes 

In y, three correctness properties for programs are introduced: nicely moded, 
well typed, and simply moded. The idea of these concepts is that in a query, 
every piece of data is produced (output) before it is consumed (input), and 
every piece of data is produced only once. It is assumed that each predicate has 
a single mode. Nicely-modedness is used to show that the occur-check can safely 
be omitted. Well-typedness is used to show that derivations do not fiounder. 
Finally, simply-modedness is a special case of nicely-modedness and is used to 
show that a program is free from errors related to built-ins. Other authors have 

^ Note that in the (pathological) case that p has a block declaration p {?, ...,?), an 
atom using p can never be selectable. 

® Whether or not the substitution has been applied is always clear from the context. 
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also used these or similar concepts, for example to show that programs are 
unification free Q, successful Q, and terminating Q. 

In a query (clause body), one can consider three different orderings among 
the atoms. First, there is the textual order. Secondly, there is a conceptual order 
given by the producer- consumer relation According to this order, the atom 

that produces a piece of data occurs before atoms that consume it. Thirdly, there 
is the execution order, which depends on the selection rule. 

In the case of LD-derivations, all of these orders are identical. This assump- 
tion underlies the above concepts as used in 

In the case of arbitrary delay-respecting derivations, none of these orders is 
necessarily identical to another one. However, since the textual order is irrelevant 
for the selection of an atom and hence for the execution order, one might just 
as well assume, for the sake of notational convenience, that the textual order is 
identical to the producer-consumer order. Although not explicitly stated, this 
assumption underlies the above concepts as used in Q. More precisely, any 
result stated there can be generalised trivially to programs where the atoms in 
the clause bodies are permuted in an arbitrary way. 

In the case of left-based derivations, again none of these orders is necessarily 
identical to another one. However, the textual order is relevant for the execution 
order. Therefore it is not correct to make a simplifying assumption about the 
textual order as for arbitrary delay-respecting derivations. We need a formalism 
that makes both the textual order and the producer-consumer order explicit. 

This is accomplished by associating, with each query and each clause in 
a program, a permutation tt of the (body) atoms, which gives the producer- 
consumer order. For a different mode, the permutations would be different. Let 
TT be a permutation on {1, . . .,n}. For notational convenience we assume that 
7t(z) = i for i ^ {1, . . . , n}. In examples, tt is written as (7t(1), . . . , 7r(n)). Also, 
we write 7t(oi, . . . , o„) for the sequence obtained by applying tt to the sequence 
0 i , . . . , On-, that is . . . , . 

Note that most results in this paper hold for arbitrary delay-respecting 
derivations, but the result in Subsec. assumes left-based derivations. For 

the sake of consistency we use the permutations throughout. 

3.1 Permutation Nicely Moded Programs 

In a nicely moded query, a variable in an input position does not occur later in 
an output position, and each variable in an output position occurs only once. 
This has been generalised in Q. 

Definition 3.1 (permutation nicely moded). Let Q = pi(si, ti), . . . , 
Pn{sn,tn) be a query and tt a permutation on {1, . . .,n}. Then Q is 7r-nicely 
moded if ti, . . . , t„ is a linear vector of terms and for all i G {1, . . . , n} 

vars{si) n [J vars{tj) = 0. 

7r(z)<7r(_j)<n 



The query tt{Q) is a nicely moded query corresponding to Q. 
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The clause C = p(to,s„+i) <— Q is 7r-nicely moded if Q is 7r-nicely moded 
and to, . . .,t„ is a linear vector of terms. The clause p(to,s„+i) ^ 7r(Q) is a 
nicely moded clause corresponding to C. 

A query (clause) is permutation nicely moded if it is 7r-nicely moded for 
some 7T. A program P is permutation nicely moded if all of its clauses are. 
A nicely moded program corresponding to P is a program obtained from 
P by replacing every clause C with a nicely moded clause corresponding to C. 

Example 3.1. 

block permute!-,-), 
permute! [] , [] ) . 
permute! [U I X] ,Y) :- 
permute !X, Z) , 
delete!U,Y,Z) . 

:- block delete!?,-,-). 
delete!X, [X|Z] ,Z) . 

delete!X, [U|Y] , [U|Z] ) :- delete!X,Y,Z) . 

In mode {permute(/, O), delete(/, O, /)}, this program is nicely moded. In 
mode {permute) O, /), delete(0, /, O)}, it is permutation nicely moded, since 
the second clause for permute is (2, l)-nicely moded, and the other clauses are 
nicely moded. 

Example 3.2. 

block length!-,-). 
length!L,N) :- len_aux!L,0,N) . 

:- block len_aux!?,-,?) , len_aux!-, ? ,-) . 
len_aux! [] ,N,N) . 
len_aux! [_ |Xs] ,M,N) :- 
less!M,N) , 

M2 is M + 1, 
len_aux!Xs,M2,N) . 

:- block less!?,-), less!-,?). 
less!A,B) :- A < B. 

This program is permutation nicely moded in mode {length)/, O), 
len_aux(/, /, O), less)/,/), is(0,/)} (the third clause is (3, 1, 2)-nicely 
moded). In mode {length(0, /), len_aux(0, /, /), less)/,/), is(0,/)}, it is 
not permutation nicely moded, since the input arguments of len_aux! [] ,N,N) 
are not linear. 

We now recall a persistence property of permutation nicely-modedness 

Lemma 3.1. Every resolvent of a permutation nicely moded query Q and a per- 
mutation nicely moded clause C, where vars{C) n vars{Q) = 0, is permutation 
nicely moded. 

For permutation nicely moded programs and queries, the occur-check can be 
omitted ^^9. 
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3.2 Permutation Well Typed Programs 

Well-typedness is a generalisation of a simpler concept called well-modedness 
The idea is that given a query Q, a, Q', when Q is resolved away, then the atom 
a becomes sufficiently instantiated to be selected. As with modes, we assume 
that the types are given. In the examples, they will be the obvious ones. 

Definition 3.2 (permutation well typed | ■ " | ). Let Q = pi(si, ti), . . . , 
p„(s„, t„) be a query, where Pi(Si, T^) is the type of pi for each i G {1, . . . , n}. Let 
7T be a permutation on {1, . . . , n}. Then Q is 7r-well typed if for alii G {1, . . . , n} 
and L = 1 

H ( /\ tj : Tj) Si : S^. (1) 

The clause (to,s„+i) ^ Q, where p(Tq, S„+i) is the type of p, is 7r-well typed 
if B holds for all z S {1, . . . , n + 1} and L = 0. 

A permutation well typed query (clause, program) and a well typed 
query (clause, program) corresponding to a query (clause, program) are de- 
fined in analogy to Def.^H 

Example 3.3. Consider the program in Ex. type {permute(^zsf, ^zst), 

delete(anp, ^zst)}. It is well typed for mode {permute(/, O), 
delete(/, O, /)}, and permutation well typed for mode {permute(0, /), 
delete) O,/, O)}, with the same permutations as Ex. ^3 The same holds as- 
suming type {permute(n^, n/), delete(num, n^, n^)}. 

The following lemma is analogous to Lemma^Jand has also been stated in . 

Lemma 3.2. Every resolvent of a permutation well typed query Q and a per- 
mutation well typed clause C, where vars{C)C\vars{Q) = 0, is permutation well 
typed. 

For permutation well typed programs and queries, no derivation flounders 

3.3 Permutation Simply Typed Programs 

We now define permutation simply-typedness. The name simply typed is a combi- 
nation of simply moded Q and well typed. In a permutation simply typed query, 
the output positions are filled with variables, and therefore they can always be 
instantiated so that they are correctly typed. 

Definition 3.3 (permutation simply typed). Let Q = pi(si, ti), . . . , 
Pn{sn, t„) be a query and tt a permutation on {!,..., n}. Then Q is 7r-simply 
typed if it is 7r-nicely moded and zr-well typed, and ti, . . .,t„ is a vector of 
variables. 

The clause p(to,s„+i) ^ Q is zr-simply typed if it is zr-nicely moded and 
TT-well typed, ti, . . .,t„ is a vector of variables, and to has a variable in each 
position of variable type and a flat term in each position of non- variable type. 

A permutation simply typed query (clause, program) and a simply 
typed query (clause, program) corresponding to a query (clause, program) 
are defined in analogy to Def. ^3 
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Example 3.4- The following is a versi on of quicksort, where leq and grt are 
defined in analogy to less in Ex. ^3 

: - block qs . 
qs( [],[]). 
qs([X|Xs] ,Ys) 

append (As2 , [X |Bs2] ,Ys) , 
part (Xs , X, As ,Bs) , 
qs (As , As2) , 
qs(Bs,Bs2) . 

block part(?,-,?,?) , part , part . 
part([], _,[],[]). 
part ( [X I Xs] ,C, [X I As] ,Bs) : - 
leq(X,C), 
part (Xs , C, As ,Bs) . 
part ([X|Xs] ,C,As, [X|Bs]) 
grt(X,C), 
part (Xs , C, As ,Bs) . 

block append(- , ? , . 
append ( [] ,Y, Y) . 
append( [X I Xs] , Ys, [X I Zs] ) 
append(Xs,Ys,Zs) . 

The program is permutation simply typed with respect to the obvious types 
for mode {qs(/, O), append(/,/, O), leq(/,/), grt(/,/), part(/,/, O, O)}. It 
is not permutation simply typed for mode {qs(0, 1), append(0, O, I), leq(/, I), 
grt(/,/), part(0, /, /, /)}, due to the non-variable term [X|Bs2] in an output 
position. 

The persistence properties stated in Lemmas^3^'^d^3^'^® independent of the 
selectability of an atom in a query. We show a similar persistence property for 
permutation simply typed programs. However this property only holds if the 
selected atom is sufficiently instantiated in its input arguments, since otherwise 
output positions of the resolvent might become non- variable. This motivates the 
following definition. 

Definition 3.4 (bound position). Let P be a permutation simply typed pro- 
gram. An input position of a predicate p in P is bound if there is some clause 
defining p whose head has a non-variable term in that position. 

Note that by Def. ^3 ^ bound position must be of non- variable type. 

Lemma 3.3. Let Q = pi(si, ti), . . ,,pn{sn, t„) be a permutation simply typed 
query and C = pfc(vo,Um+i) ^ gi(ui,Vi), . . .,gm(um,Vm) a permutation sim- 
ply typed clause where vars(C) fl vars(Q) = 0. Suppose that for some k G 
{!,..., n}, pfc(sfc, tfc) is non-variable in all bound input position J and 9 is the 
mgu of pfc(sfc, tfc) and Pki'^o, Um-i-i)- Then the resolvent of Q and C with selected 
atom pfc(sfc,tfc) is permutation simply typed. Moreover, 

This is similar to “the delay declarations imply matching” 3- 



4 
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a. dom{6) C vars{tk) U t;ars(vo), and 

b. . . .,t^) 0 — 

Proof. By assumption is non-variable in all bound positions, and Vq is a 
linear vector having flat terms in all bound positions, and variables in all other 
positions. Furthermore Vq is linear. Thus there is a substitution 9i such that 
Vo6*i = Sfc and dom{9i) C vars(vo). 

Since is a linear vector of variables, there is a substitution 02 such that 
dom{92) C varsftk) and tfc 02 = Um-i-i0i. 

Since Q is 7r-nicely moded, vars(tk) r\vars{sk) = 0, and therefore varsftk) H 
vars{vo9i) = 0. Thus it follows by the previous paragraph that 9 = 0i02 is a 
unifier of pfc(sfc,tfc) and pfc(vo, u^-i-i). holds since dom{9i) C vars(vo) and 
dom{92) C vars{tk). Bfollows from l|f because of linearity. 

By Lemmas^3^'^if^^^| the resolvent is permutation nicely moded and per- 
mutation well typed. By Q, the vector of the output arguments of the resolvent 
is a linear vector of variables, and hence the resolvent is permutation simply 
typed. □ 

The following corollary of Lemma^^holds since by Def.^J the leftmost atom 
in a simply typed query is non-variable in its bound input positions. 

Corollary 3.4. Every LD-resolvent of a simply typed query Q and a simply 
typed clause C, where vars{C) fl vars{Q) = 0, is simply typed. 

The following definition gives a name to the condition that the selected atom 
must always be non-variable in bound input positions. 

Definition 3.5 (input selectability). Let P be a permutation simply typed 
program. P has input selectability if, for every permutation simply typed 
query Q, an atom in Q is selectable in P if and only if and only it is non- variable 
in all bound input positions. 

In a permutation simply typed query, the output positions of each atom are 
filled with variables. This gives us a way of checking input selectability: the 
block declarations must be such that an atom whose output positions are all 
variable is selectable if and only if all bound input positions are non-variable. 

Note that for input selectability, it is sufficient that the selected atom is non- 
variable in the bound input positions. It is not necessary that all input positions, 
or even all input positions of non-variable type, are non-variable. 

Example 3.5. Consider Ex. In mode delete(/, O,/), the third position is 
the only bound input position. In mode delete(0, /, O), the second position is 
the only bound input position. The block declarations ensure input selectability. 
This is true assuming any type given in Ex. ^3 

The next lemma says that in a derivation for a permutation simply typed pro- 
gram and query, it can be assumed without loss of generality that the output 
positions in each query are filled with variables that occur in the initial query 
or in some clause body used in the derivation. 
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Lemma 3.5. Let P be a permutation simply typed program with input se- 
lectability and Qo be a permutation simply typed query. Let 6q = % and ^ = 
(Qo, ^o); {Qii&i)', ■ ■ ■ be a delay-respecting derivation of P U {Qo}- Then for all 
i > 0, if a; is a variable occurring in an output position in Qi, then x9i = x. 

Proof. The proof is by induction on the position i in the derivation. The base 
case i = 0 is trivial sin ce 9q = 0. Now suppose the result holds for some i and 
Qi+i exists. By Lemma^3Qj0i is permutation simply typed. Thus the result 
follows for i -I- 1 by Lemma^HH. □ 

4 Errors Related to Built-ins 

One problem with built-ins is that their implementation may not be written in 
Prolog. Thus, for the purposes of this paper, it is assumed that each built-in is 
conceptually defined by possibly infinitely many (fact) clauses. The ISO standard 
for Prolog B does not define the built-in predicates as conceptual clauses, but 
it is nevertheless so precise that it should generally be possible to verify whether 
such a definition is correct. 

To prove that a program is free from errors related to built-ins, we require 
it to meet certain correctness conditions some of which have been introduced 
in the previous section (see Definitions^J^J^J. The correctness conditions 
have to be satisfied by the conceptual clauses for the built-ins as well as by the 
user-defined part of the program. 

For instance, consider the atom M2 is M + 1 in Ex. Conceptually, we 
regard this as an atom with two arguments M2 and M, and we assume that there 
are facts “1 is 0+1.”, “2 is 1+1 .”, and so forth. 

Some built-ins produce an error if certain arguments have a wrong type, 
and others produce an error if certain arguments are insufficiently instantiated. 
For example, X is foo results in a type error and X is V results in an 
instantiation error. In this section, we consider two approaches to ensure freedom 
from instantiation and type errors due to the presence of delay declarations. 
For different programs and built-ins, different approaches are applicable. Under 
certain conditions, we even show that no delay declarations are needed at all. 



4.1 The Connection between Delay Declarations and Type Errors 

At first sight, it seems that delay declarations do not affect the problem of type 
errors, be it positively or negatively. Delay declarations cannot enforce arguments 
to be correctly typed. Also, one would not expect that a selection rule that is 
not left-to-right could be the cause of wrongly typed arguments. 

This is probably true in practice, but in theory, there is an aspect of type 
errors that is specifically related to delay declarations. Consider the program con- 
sisting of the fact clause ‘two (2) .’ and the built-in is, with type {two(num), 
±s{num,num)} and mode {two(O), is(0, /)}. The query 



X is foo, two(foo) 
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is (2, l)-well typed since trivially |= f oo : num ^ f oo : num. That is, since the 
output of two is wrongly typed, we can say that correctly typed output of two 
implies correctly typed input for is. The above query results in a type error. 

For LD-derivations this problem does not arise. The well typed query corre- 
sponding to the above query is two(foo), X is foo. Since the type of two is 
num and the program is well typed, the atom two (foo) can never be resolved, 
and therefore the derivation fails without ever reaching X is foo. 

4.2 Exploiting Constant Types 

The approach described in this subsection aims at preventing instantiation and 
type errors for built-ins, for example arithmetic built-ins, that require arguments 
to be ground. It has been proposed in Q that these predicates be equipped 
with delay declarations to ensure that they are only executed when the input is 
ground. This has the advantage that one can reason about arbitrary arithmetic 
expressions, say quicksort ( [1+1 ,3-8] ,M) . The disadvantage is that block dec- 
larations cannot be used. In contrast, we assume that the type of arithmetic 
built-ins is the constant type num, rather than arithmetic expressions. Then we 
show that block declarations are sufficient. The following lemma is similar to 
and based on Q Lemma 27]. 

Lemma 4.1. Let Q = pi(si,ti), . . .,p„(s„,t„) be a 7r-well typed query, where 
Pi{Si,Ti) is the type of pi for each i G {!,..., n}. Suppose, for some k G 
{!,..., n}, Sfc is a vector of constant types, is a vector of non-variable terms, 
and there is a substitution 9 such that tjO : Tj for all j with 7r(j) < 7r(fc). Then 
Sfc : Sfc (and thus Sfc is ground). 

Proof. By Def. Sfc6* : Sfc, and thus Sfc6* is a vector of constants. Since Sfc is 
already a vector of non-variable terms, it follows that Sfc is a vector of constants 
and thus Sfc0 = Sfc. Therefore Sfc : Sfc. □ 

By Def. for every permutation simply typed query Q, there is a 0 such 
that Q9 is correctly typed in its output positions. Thus by Lemma^Jif the 
arithmetic built-ins have type num in all input positions, then it is enough to 
have block declarations such that these built-ins are only selected when the 
input positions are non-variable. This is stated in the following theorem which 
is a consequence of Lemma^H 

Theorem 4.2. Let P be a permutation simply typed program with input se- 
lectability and Q be a permutation simply typed query. Let p be a predicate 
whose input arguments are all of constant type. Then in any derivation of 
P U {Q}, an atom using p will be selected only when its input arguments are 
correctly typed. 



Example 4-1 ■ Consider the program in Ex. ^^in mode qs(/, O). No delay- 
respecting derivation for a permutation simply typed query and this program 
can result in an instantiation or type error related to the arithmetic built-ins. 
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4.3 Atomic Positions 

Sometimes, when the above method does not work because a program is not 
permutation simply typed, it is still possible to show absence of instantiation 
errors for arithmetic built-ins. We observe that these built-ins have argument 
positions of the constant type num. Thus, the idea is to declare certain argument 
positions in a predicate, including the above argument positions of the built-ins, 
to be atomic. This means that they can only be ground or free but not partially 
instantiated. Then there needs to be a block declaration such that an atom 
delays until the arguments in these positions are non- variable, and hence ground. 
Just as with types and modes, we assume that the positions which are atomic 
are already known. 

Definition 4.1 (respects atomic positions). A query (clause) respects 
atomic positions if each term in an atomic position is ground or a variable 
which only occurs in atomic positions. A program respects atomic positions if 
each of its clauses does. 

A program need not be permutation nicely moded or permutation well typed in 
order to respect atomic positions. 

Lemma 4.3. Let C be a clause and Q a query which respect atomic positions, 
where vars(C) fl vars{Q) = 0. Then every resolvent of C and Q also respects 
atomic positions. 

Proof. Let Q = oi, . . . , a„ be the query and C = /i ^ 6i, . . . , 6m be the clause. 
Let Ofc be the selected atom and assume it is unifiable with h using mgu 9. We 
must show that 

Q — ■ ■ ■ 5 ^k—li 6l, . . . , 6m, . . . , ari)9 

respects atomic positions. 

Let a; be a variable which fills an atomic position in Ofc or h. Since Q and 
C respect atomic positions, x9 is either a variable which only occurs in atomic 
positions in Q', or a ground term. 

Consider a term s filling an atomic position in oi, . . . , ai-i, Oi+i, . . . , a„ or 
6i, . . . , 6m. If s is a ground term, then s9 is also a ground term. Suppose that 
s is a variable. If s ^ dom{9), then s9 is also a variable. If s G dom{9) then s 
must fill an atomic position in Ofc or h. By the previous paragraph, s9 is either 
a variable which only occurs in atomic positions in Q' , or a ground term. □ 

Using Lemma^3we can show freedom from instantiation errors for programs 
where the arguments of type num are variable-disjoint from any other arguments. 

Example J^.2. Consider the program for length in Ex.^3 If the atomic positions 
are exactly those positions with arithmetic arguments, then the program respects 
atomic positions. The block declaration on the built-in < is realised with an 
auxiliary predicate less. 
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Note that in the second clause for len_aux, for each mode, the input for is 
is provided by the clause head. Therefore no block declaration and hence no 
auxiliary predicate is required for is — it is sufficient to have a block declaration 
for len_aux. This is formalised by the following definition and lemma. 

Definition 4.2 (K-ground). Let P be a program which respects atomic posi- 
tions and B a set of predicates whose input positions are all atomic. 

A query is P-ground if it respects atomic positions and each atom using a 
predicate in B has ground terms in its input positions. 

An argument position fc of a predicate p in P is a ,B-position if there is a 
clause p(to,s„+i) <— pi(si, ti), . . . ,p„(s„, t„) in P such that for some i where 
Pi G B, some variable in also occurs in position k in p(to,s„+i). 

The program P is P-ground if every P-position of every predicate in P is 
an atomic input position, and an atom p(s, t), where p ^ B, is selectable only if 
it is non- variable in the P-positions of p. 

By the following theorem, for P-ground programs and queries it is always guar- 
anteed that the input of all atoms in B is ground, since that input originates 
either from the initial query or the clause head. 

Theorem 4.4. Let P and Q be a P-ground program and query, and ^ be a 
delay-respecting derivation of PU {Q}- Then each query in ^ is P-ground. 

Proof. The proof is by induction on the length of f. Let Qo = Q and Qo; Qi; ■ ■ ■ 
be a delay-respecting derivation of P U {Qo}- Tbe base case holds by the as- 
sumption that Qo is P-ground. 

Now consider some Qj where } > 0 and Qj+i exists. By Lemma^H Qj and 
Qj+i respect atomic positions. 

Let p(u, v) be the selected atom, C = p{to, s„+i) <— pi(si, ti), . . . ,p„(s„, t„) 
be the clause and 9 the mgu used in the step Qj] Qj+i- Consider an arbitrary 
i G {1, . . . , nj such that pt G B. We have to distinguish two cases. 

li p ^ B, then by Def. u is non- variable in the ;B-positions of p, and 
hence, since Qj respects atomic positions, u is ground in the P-positions of p. 
lip G B, then u is ground in the P-positions oip by the induction hypothesis. 
Thus it follows that in both cases, Si9 is ground. Since the choice of i was 
arbitrary, it follows that Qj+i is P-ground. □ 

Example 4-3. The program of Ex.^Ji s {is |-ground, and the second position 
of len_aux is an (isj-position. By Thm.^3 it is justified that there is no block 
declarations for is. 

5 Termination 

We are interested in ensuring that all derivations of a query are finite. There- 
fore the clause order in a program is irrelevant. Furthermore, we do not prove 
termination as such, but rather reduce the problem of proving termination for a 
program with block declarations to the same problem for a corresponding pro- 
gram without block declarations. We always assume that termination for the 
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latter program can be shown using an existing method for LD-derivations 
We present two methods for showing termination, which are illustrated in the 
following example. 

Example 5.1. The query permute (Vj[l] ) (Ex. loops because delete pro- 
duces a speculative output binding The output variable Y is bound before 
it is known that this binding will never have to be undone. Assuming left-based 
derivations, termination in both modes can be ensured by replacing the second 
clause with 

permute ( [U I X] ,Y) 
delete(U,Y,Z) , 
permute (X,Z) . 

This technique has been described as putting recursive calls last Q. 

To explain termination of this program, we have to apply a different rea- 
soning for the different modes. In mode permute (0,J), the atom that produces 
the speculative output occurs textually before the atom that consumes it. This 
means that the consumer waits until the producer has completed (undone the 
speculative binding). The program does not use speculative bindings. In mode 
permute (/, O) , delete is used in mode delete(/, 0,1), and in this mode it 
does not make speculative bindings. 

Note that termination for this example depends on derivations being left- 
based, and so any method which abstracts from the selection rule must fail. 

Both methods described below formalise previous heuristics and rely on 

conditions that are easy to check. It can be shown using these methods that 
Ex. will terminate. These methods are not adequate for Ex. ^3 A more 
complex method suitable for Ex. described in However, we will also 

give two examples of programs for which termination can be shown using the 
methods described here, but not using the method of 

5.1 Termination by not Using Speculative Bindings 

In LD-derivations, speculative bindings are never used A left-based der- 
ivation is an LD-derivation, provided the leftmost atom in each query in the 
derivation is always selectable. This implies the following proposition. 

Proposition 5.1. Let Q be a well typed query and P a well typed program 
such that an atom is selectable in P whenever its input positions of non- variable 
type are non-variable. Then every left-based derivation of P U {Q} is an LD- 
derivation. 

We now give two examples of programs where by Prop. ^3 can use any 
method for LD-derivations to show termination for any well typed query. 

Example 5.2. Consider permute(0, /) as defined in Ex. either of the 

types given in Ex. ^3 This program is well-typed. 



Example 5.3. Consider the following version of delete(0, 1 , O). 
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block deleteC?,-,-) . 
deleteCX, [X|Z] ,Z) . 

deleteCX, [U| [HIT]] , [U|Z]) delete (X, [H I T] , Z) . 

Assuming either of the types given in Ex. ^3 this program is well typed. Note 
that for this program, the method of ^9 is not applicable. 

5.2 Termination by not Making Speculative Bindings 

Some programs have the nice property that there cannot be any failing deriva- 
tions. In Q, such a class of programs called noFD was identified. Non- speculative 
programs are similar, but there are two differences: the definition of noFD pro- 
grams allows only for LZAderivations, but on the other hand, the definition of 
non-speculative programs requires that the clause heads are input linear. 

Definition 5.1 (non-speculative). A program P is non-speculative if it is 

permutation simply typed, has input selectability, and every simply typed aton| 
using a predicate in P is unifiable with some clause head in P. 



Example 5.J^. Both versions of the permute prog ram (Examples ^3 and ^3, 
assuming either of the types given in Ex. ^3 ^re non-speculative in mode 
{permute(/, O), delete)/, 0,1)}. Every simply typed atom is unifiable with 
at least one clause head, and the block declarations ensure input selectability. 

Both versions of the permute program are not non-speculative in mode 
{permute(0, /), delete(0, /, O)}, because deleteCA, [] ,B) is not unifiable 
with any clause head. 

A delay-respecting derivation for a non-speculative program P and a permuta- 
tion simply typed query can neither flounder nor fail. However it could still be 
infinite. Theorem^^^ays that this can only happen if the simply typed program 
corresponding to P also has an infinite (LD-)derivation for this query. 

Theorem 5.2. Let P be a non-speculative program and P' a simply typed 
program corresponding to P. Let Q be a permutation simply typed query and Q' 
a simply typed query corresponding to Q. If there is an infinite delay-respecting 
derivation of PU {Q}, then there is an infinite LD-derivation of P' U {Q'}. 

Proof. For simplicity assume that Q and each clause body do not contain two 
identical atoms. Let Qo = Q, Oq = ^ and f = {Qo, 6q)-, (Qi, 6 *i); ... be a delay- 
respecting derivation of PU {Q}. The idea is to construct an LD-derivation of 
P' U {Q'} such that whenever f uses a clause C, then f uses the corresponding 
clause C" in P'. It will then turn out that if is finite, f must also be finite. 

We call an atom a resolved in ^ at z if a occurs in Qi but not in Qi+i. 
We call a resolved in f if for some i, a is resolved in f at i. Let Qo = Q' 

0Q = 0. We construct an LD-derivation f = (Qq, 9q); {Q[,9[); . . . of P' U {Q'| 
showing that for each z > 0 the following hold: 

We say “atom” for “query of length 1” . 
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(1) If g(u,v) is an atom in O', that is not resolved in £, then varsiwO',) H 
dom{ej) = 0 for all j > 0. 

(2) Let a; be a variable such that, for some j > 0, x6j = /(. . .). Then x6'^ is 
either a variable or x9'^ = /(. . .). 

We first show these properties for z = 0. Let g(u,v) be an atom in Qq that is 
not res olved in Since O'q = 0, v6*q = v. Furthermore, by Corollary and 
Lemma^3and since g(u, v) is not resolved in we have = v for all j. Thus 
(1) holds. (2) holds because = 0. 

Now assume that for some i, {Q'^,6'^) is defined, Qi is not empty, and (1) 
and (2) hold. Let p(s, t) be the leftmost atom of Q'. We define a derivation step 
with p{s, t) as the selected atom, and show that (1) and (2) 

hold for 

Case 1: p(s, t) is resolved in ^ at / for some 1 . Consider the simply typed clause 
C = h ^ B' corresponding to the uniquely renamed clause (using the same 
renaming) used in ^ to resolve p(s,t). Since p{s,t) is resolved in ^ at I, p{s,t)9i 
is non-variable in all bound input positions. Thus each bound input position of 
p(s, t) must be filled by a non- variable term or a variable x such that x9i = /(. . .) 
for some /. Moreover, p(s,t)0' must have non-variable terms in all bound input 
positions since Q'0' is well typed. Thus it follows by (2) that in each bound 
input position, p(s,t)6*' has the same top-level functor as p{s,t)9i, and since h 
has flat terms in the bound input positions, there is an mgu (|)'^ of p(s,t)0( and 
h. We use C for the step (Q', 0'); (Q'+i, 

We must show that (1) and (2) hold for z -|- 1. Consider an atom g(u, v) in 
g' other than p(s,t). By Lemma^HH, vars{v9'^) C dom{cj)^) — 0. Thus for 
the atoms in that occur already in g(, (1) is maintained. Now consider an 
atom g(u,v) in B' which is not resolved in By Lemma^J = v. Since 

g(u, v) is not r esolv ed in for all j > I we have that g(u, v) occurs in Qj and 
thus by Lemma^J v9j = v. Thus (1) follows. (2) holds since it holds for z and 
p{s,t) is resolved using the same clause head as in 

Case 2: p(s,t) is not resolved in Since P' is non-speculative, there is a 
(uniquely renamed) clause C" = /z <— i?' in P' such that h and p(s, t)0( have an 
mgu (/>'. We use C for the step (g(, 0'); 

We must show that (1) and (2) hold for z -|- 1. Consider an atom g(u, v) in 
g' other than p{s, t). By Lemma^HO, vars{v9'^) n dom{(j)^) = 0. Thus for the 
atoms in that occur already in g(, (1) is maintained. Now consider an atom 
g(u, v) in B' . Clearly g(u, v) i s not resolved in Since z;ars(C')nz;ars(gj6*j) = 0 
for all j and since by Lemma^3 have = v, (1) holds for z -|- 1. 

By (1) for z, we have vars{t9'^) n dom{9j) = 0 for all j. By Lemma^Hj^, 
we have dom{(j)'^) C vars{t9[) U vars{C). Thus we have dom{(j)'^) n dom{9j) = 0 
for all j. Moreover, (2) holds for z. Thus (2) holds for z -|- 1. 

Since this construction can only terminate when the query is empty, either 
g(j is empty for some n, or is infinite. 

Thus we show that if is finite, then every atom resolved in ^ is also re- 
solved in So let be finite of length n. Assume for the sake of deriving a 
contradiction that j is the smallest number such that the atom a selected in 
{Qj,9j}-, (Qj+i,9j+i) is never selected in Then j ^ 0 since Qo and Q'q are 
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permutations of each other and all atoms in Qo are eventually selected in Thus 
there must be a fc < j such that a does not occur in Qk but does occur in Qk+i- 
Consider the atom b selected in {Qk, Ok); {Qk+i, Ok+i). Then by the assumption 
that j was minimal, b must be the selected atom in {Q{, 6{); (Q'+i > ^i+l) for some 
i < n. Hence a must occur in since the clause used to resolve b in is a 
simply typed clause corresponding to the clause used to resolve b in Thus a 
must occur in Q'^, contradicting that terminates with the empty query. 

Thus ^ can only be infinite if is also infinite. □ 

Theorem^Hsays that for non-speculative programs, atom order in clause bodies 
is irrelevant for termination. In other words, termination is independent of any 
particular selection rule, as long as derivations are delay-respecting. 

We now give an example of a program for which termination can be shown 
using non-speculative programs but not using the method of ^3- 

Example 5.5. The following program has mode {plus_one(/), minus_two(/), 
minus_one(/), two(O), one(O), zero(O)}, and the type of all arguments is nl. 

block plus_one(-). 
plus_one(X) minus_two( [1 |X] ) . 

block minus_two (-) . 
minus_two ( [A I X] ) minus_one(X) . 
minus_two ( [] ) . 

block minus_one (-) . 
minus_one ( [A I X] ) plus_one(X). 
minus_one ( [] ) . 

two([2|X]) one(X). 

one([l|X]) zero(X). 

zero( [] ) . 

This program is non-speculative, and the query 

Q = plus_one(X), two(X) 

is (2, l)-simply typed. Moreover, it is easy to see that, for the corresponding 
simply typed query two(X), plus_one(X) , any L£)-derivation is finite. Therefore 
by Thm.^H all delay-respecting derivations of Q are finite. 

6 Related Work 

This work was inspired by Apt and Luitjes Q. For arithmetic built-ins, they 
require declarations which delay an atom until the arguments are ground. Such 
declarations are usually implemented not as efficiently as block declarations. 
Little attention is given to termination, proposing a method limited to deter- 
ministic programs. 
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Naish gives good intuitive explanations why programs loop, which di- 
rected our own search for further ideas and their formalisation. To ensure ter- 
mination, he proposes some heuristics, without any formal proof. 

Predicates are assumed to have a single mode. Alternative modes are achieved 
by multiple versions of a predicate. This approach is quite common and is 

also taken in Mercury where these versions are generated by the compiler. 
However, generating multiple versions implies code duplication and hence there 
is a loss of generality in assuming single-moded predicates. 

Naish uses examples such as permute where under the above assumption, 
there is no reason for using delay declarations in the first place. Therefore, his 
discussion on delay declarations lacks motivation. 

Liittringhaus-Kappel Q proposes a method to generate control auto- 
matically to ensure termination, giving practical evidence that control declara- 
tions were generated for many programs. The method assumes arbitrary delay- 
respecting derivations and hence does not work for programs where termination 
depends on derivations being left-based. 

Marchiori and Teusink Q base termination on norms and the covering 
relation between subqueries of a query. This is loosely related to well-typedness. 
However, their results are not comparable to ours because they assume a local 
selection rule, that is a rule which always selects an atom which was introduced 
in the most recent step. We are not aware of an existing language that uses a 
local selection rule. The authors state that programs that do not use speculative 
bindings deserve further investigation, and that they expect any method for 
proving termination with full coroutining either to be very complex, or very 
restrictive in its applications. 

We have previously presented a method of proving termination which is based 
on identifying the so-called robust predicates, for which the textual position of 
an atom using this predicate is irrelevant ^3- That method is quite complex 
and not as intuitive as the methods described here. In practice, it is probably 
more widely applicable than the method of this paper, but we have seen in 
Examples and that there are programs for which the methods of this 
paper work and the method of ^9 does not. 

7 Conclusion and Future Work 

We have shown methods of preventing instantiation and type errors related to 
built-ins and ensuring termination for logic programs with block declarations. 

To prevent errors due to built-ins, we have provided two methods that show 
that block declarations, as opposed to more complicated delay constructs Q, 
are often sufficient. In addition, in many cases, particularly for the arithmetic 
predicates where the arguments must be atomic, we show that there is no need 
for any form of delay declarations. Whether one of these methods or even both 
are applicable depends on the program. Finding a more uniform approach to 
this problem could be a topic of future work. 
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For proving termination, we have presented two methods based on not using 
and not making speculative bindings, respectively. Proposition states that 
for well typed programs meeting a simple condition on selectability, any left- 
based derivation of a well typed query is an LD-derivation. Theorem ^3®tates 
that for non-speculative programs, termination is independent of a particular 
selection rule. We have noted that in some cases such as Ex. in one mode, 
the first method applies, and in the second mode, the other method applies. 
These methods are appealing because they are simple and formalise heuristics 
that have been known for some time 

It is an ongoing discussion whether it is reasonable to assume predicates 
that run in several modes We believe that a formalism dealing with delay 
declarations should at least allow for multiple modes, while not excluding other 
applications such as the test-and-generate paradigm (coroutining). Our results 
are still applicable and relevant for programs with just a single mode. For ex- 
ample, our results about built-ins could be used to show absence of errors in a 
program for the n-queens problem, which is a well-known example for the test- 
and-generate paradigm Also, Thm.^^is useful for single-moded programs. 
However, we admit that Prop.^3l^<^ks motivation without the assumption of 
multiple modes. 

We envisage that an implementation of our work should take the form of a 
program development tool which would help a programmer to verify the vari- 
ous mode and type conditions introduced in this paper. It should also support 
transforming a program so that the conditions are met, which would mainly be 
limited to reordering atoms in clause bodies. Further research concerning the 
design and development of such a tool is ongoing work. 
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Abstract. Starting in the early 1980s, a number of algorithmic tech- 
niques have been proposed for synthesizing the synchronization kernel 
of reactive systems from high-level temporal logic specifications. These 
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1 Introduction and Specifications 

This work is inspired by D.R. Smith’s research on synthesising global search 
(GS) programs (in the Refine language) from first-order logic specifications (also 
in Refine) We concentrate on synthesising constraint logic programs 

(CLP) Q instead. We thus only have to synthesise code that (incrementally) 
poses the constraints, because the actual constraint propagation and pruning 
are performed by the CLP system. We here only tackle the family of decision 
assignment problems; the families of optimisation assignment problems, deci- 
sion permutation problems, and optimisation permutation problems are covered 
in Q. 

Specifications are the input to program synthesis. In decision assignment 
problems, a mapping M from a list V into the integer interval 1..W has to be 
found, satisfying certain constraints. Their formal specifications take the form 

V(U, W) : list{term) x int . VM : list(V x 1..W) . , . 

r((U, W), M) ^ V(/, J), {K, L)eM. A™ ^ Pfil, J, K, L) ^ Qfil, J, K, L) 

where the Pi and Qi are formulas. This can be considered a specification template. 
This covers many problems, such as Hamiltonian path, n-Queens, and graph 
colouring, which problem consists of finding a mapping M from the list R of the 
regions of a map to a set of colours (numbered 1..C) so that any two adjacent 
regions (as indicated in an adjacency list A) have different colours: 

V(i?, C, A) : list{term) x int x list{R x R) . VM : list{R x 1..C) . , , 

col{{R, C, A),M)^ V(i?i, Cl), (i? 2 , Ca) G M . (i?i, Ra) G A ^ Ci yf Ca ^ ’ 

2 A Global Search Program Schema for CLP 

A program schema Q for a programming methodology M (such as divide- 
and-conquer, generate-and-test, ...) is a couple (T,A), where template T is 
an open program showing the (problem-independent) data-flow and control-flow 
of programs constructed following AI, and axioms A constrain the (problem- 
dependent) programs for the open relations in T such that the overall (closed) 
program will really be a program constructed following AI. 

* A full version of this extended abstract is published as 

P. Flener (Ed.): LOPSTR’98, LNCS 1559, pp. 309^B 
@ Springer-Verlag Berlin Heidelberg 1999 
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The basic idea of our GS schema for CLP is to start from an initialised 
descriptor of the search space, to incrementally split that space into subspaces, 
while declaring the domains of the involved variables and constraining them to 
achieve partial consistency, until no splits are possible and a variablised solution 
can be extracted. Then a correct solution is generated, by instantiation of the 
variables in the variablised solution. Our GS template is thus the open program: 

r{X,Y) ^ initialise{X , D) , 
rgs(X,D,Y), 
generatelY, X) 

rgs{X, D, Y) <— extract{X, D, Y) (GS) 

rgs\x, D, Y) ^ split{D, X, D',5), 
constrain{S, D, X), 
rgs{X,D',Y) 

where the open relations are informally specified as follows: initialise{X , D) 
iff D is the descriptor of the initial space of candidate solutions to problem 
X; extract{X, D, Y) iff the variablised solution Y to problem X is directly ex- 
tracted from descriptor D; split{D , X , D' , 6) iff descriptor D' describes a sub- 
space of D wrt problem X, such that D' is obtained by adding 6 to descriptor D] 
constraints, D, X) iff adding 5 to D leads to a descriptor defining a subspace of 
D that may contain correct solutions to problem X; generate{Y, X) iff correct 
solution Y to problem X is enumerated from the constraint store, which is an 
implicit parameter representing X. Formalising this is the role of the axioms, as 
shown in There we also establish in what sense our GS schema is correct. 

3 Schema Particularisations and the Synthesis Method 

Using the GS schema like the divide-and-conquer schema was used in to 
guide synthesis puts heavy demands on automated theorem proving and turns 
out much more difficult Q. Fortunately, a large percentage of GS programs falls 
into one of 7 families identified by Smith, each representing a particular case of 
the GS schema (in the sense that programs for all its open relations are ade- 
quately chosen in advance), here called a particularisation. In B, we exhibit our 
particularisations for assignment and permutation problems, and show how to 
implement them as programs, called closures, because they “close” the open pro- 
gram GS. We also define the notion of specification reduction, expressing when 
it suffices to invoke a program Pg of specification Sg to implement a new specifi- 
cation Sr - The synthesis method is then as follows: Given a specification Sr, find 
(through a linear subcase of the decidable second-order semi-unification) a sub- 
stitution 6 under which Sr reduces to the specification template Sg attached to 
some particularisation Pg of the GS schema, and then obtain a (closed) program 
that correctly implements Sr by taking the GS template and GgO. 

Example Given specification (2), the fully automatically synthesisable program 
consists of the GS template and the following code: 
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Pinit '■ initialise{X, D) ^ 

D={VA ]) 

Pextr ■ extract{_, D, Y) ^ 

D={[].Y) 

Pspiit ■ split{D, X, D' ,5) ^ 
D={[I\TIM), 

J in 1..VP, 

5= {I, J), 

D' = {T, [6\M]) 

Pconstr : constrain{_, D, _) ^ 

constrain{5, D, (_, _, ^)) ^ 

S = (Pi, Cl), 

n = (_,[(P2,C2 )Im']), 

(Pi, P2) & A ^ Cl ^ C2, 

constrain(S, (_, M'), _, ^)) 

Pgen ■ generate(M, _) <— 

M=[] 

generate(M, _) ^ 

M= [(_, J)\M'], 
indomain(J) , 
generate(M' , _) 



4 Conclusion 

At least one order of magnitude is gained in efficiency by switching from an ordi- 
nary symbolic language to a constraint one, and our automatically synthesisable 
CLP(FD) Q programs are only 3 to 5 times slower than carefully hand-crafted 
ones Q, which is encouraging since none of the obvious problem-specific op- 
timising transformations have been performed yet on our programs. Since our 
synthesis is fully automatable, starting from short and elegant formal specifica- 
tions (which can even be generated from some form of controlled English Q), 
our approach seems viable. Our formal specification language is equivalent in its 
expressiveness to CLP(Sets) programming languages, such as CLPS 0. We thus 
aim at new ways of compiling CLP(Sets) programs. Comparing execution times 
is still meaningless because of the prototypical nature of CLP (Sets) compilers. 

The synthesised programs are not small (minimum 33 atoms, in a very expres- 
sive programming language), and making them steadfast reusable components 
for a programming-in-the-large approach by embedding their whole development 
in a framework-based approach Q is straightforward. 

Our results are more than a simple transcription of the Kids approach from 
Refine to CLP, as they also reflect some new ideas. 

First, we fully exploited CLP [as opposed to Refine, which is “only” an ordi- 
nary symbolic language], by significantly modifying the original GS schema, so 
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that it reflects a constrain- and- generate programming methodology. Much of the 
constraint solving machinery that needs to be pushed into Refine programs, at 
synthesis time or at optimisation time, is already part of the CLP(FD) language 
and is implemented there once and for all in a particularly efflcient way. 

Second, we introduced the notion of specification template. This has nice 
effects on the Kids approach, as shown in the next two items. 

Third, the substitution under which a specification reduces to a specification 
template can be easily computed, so that there is no need of an automated 
theorem prover, at synthesis time, to compute it. 

Fourth, the derivation of consistency-constraint-posing code can be calling- 
context-dependent, leading to rather effective (namely incremental) constraint- 
posing code [in contrast to Smith’s calling-context-independent derivation of 
Alters BQ and cuts Q, which may be non-incremental] . Such code can even 
be pre-synthesised, for a given particularisation, so that there is no need of an 
automated theorem prover, at synthesis time, to derive its specification. [As 
opposed to Alters and cuts] no forward constraints need to be posed, not even 
for efficiency reasons, due to the way CLP programs work [as opposed to Refine 
ones] : Solution construction (through generate) actually only starts in CLP once 
all constraints have been posed, and posing any forward constraints would thus 
be not only superfluous but also a way of slowing down the program, because 
the forward constraints of time t will become backward constraints at times 
larger than t and all constraints would thus have been posed twice. This does 
not prevent CLP from performing forward checks during solution generation. 

All this means that synthesis can be fully automatic, without using any 
automated theorem prover, for some families of problems. 



References 

1. F. Ambert, B. Legeard, et E. Legros. Programmation en logique avec contraintes 
sur ensembles et multi-ensembles hereditairement finis. TSI 15(3):297-328, 1996. 

2. D. Diaz and Ph. Codognet. A minimal extension of the WAM for clp(FD). In: D.S. 
Warren (ed), Proc. of ICLP’93, pp. 774-790. The MIT Press, 1993. 

3. P. Flener, K.-K. Lau, and M. Ornaghi. Correct-schema-guided synthesis of stead- 
fast programs. Proc. of ASE’97, pp. 153-160. IEEE Computer Society Press, 1997. 

4. P. Flener, H. Zidoum, and B. Hnich. Schema-guided synthesis of constraint logic 
programs. Proc. of ASE’98. IEEE Computer Society Press, 1998. 

5. N.E. Fuchs and U. Schwertel. Attempto Controlled English — Not just another 
logic specihcation language. This volume. 

6. J. Jaffar and M.J. Maher. Constraint logic programming: A survey. J. of Logic 
Programming 19-20:503-582, 1994. 

7. D.R. Smith. Top-down synthesis of divide- and- conquer algorithms. Artificial In- 
telligence 27(l):43-96, 1985. 

8. D.R. Smith. The structure and design of global search algorithms. TR 
KES.U.87.12, Kestrel Institute, 1988. 

9. D.R. Smith. Kids: A semiautomatic program development system. IEEE Trans. 
Software Engineering 16(9): 1024-1043, 1990. 

10. D.R. Smith. Towards the synthesis of constraint propagation algorithms. In: Y. 
Deville (ed), Proc. of LOPSTR’93, pp. 1-9, Springer- Verlag, 1994. 



Abstract: Proof Planning with Program Schemas 



Julian Richardson* 



Institute of Representation and Reasoning, Division of Informatics, Edinburgh 
University, 80 South Bridge, Edinburgh EHl IHN, Scotland 
julianrOdai .ed.ac.uk 



1 Introduction 

Schema-based program synthesis and transformation techniques tend to be either 
pragmatic, designed for carrying out real program transformation or synthesis 
operations but lacking the logical basis to ensure correctness of the programs 
they synthesise/transform, or rigorous, with strong theoretical foundations, but 
generating proof obligations which are difficult to satisfy. 

What is needed is a framework which can address the rigorous logical foun- 
dations of schemas at a sufficient level of abstraction to make schema-based 
program synthesis and transformation practical while retaining correctness. We 
propose that proof planning offers a paradigm which combines logical rigour with 
usability, and, in addition, allows the employment of schemas to be integrated 
with the automatic satisfaction of any proof obligations which arise. 

Further details of the work described in this abstract can be found in 

2 Proof Planning 

Machine-assisted proofs are generally made up of many small steps. The depth 
and large branching rate mean that a large search space must be explored in 
order to generate them automatically, and they can be hard to understand. 
Proof planning addresses these issues by providing a more high-level view of the 
proof. This not only makes proofs easier to generate by reducing the size of the 
proof search space, but also aids the user by producing proofs which are made 
up of a small number of understandable steps. This is especially important when 
a proof attempt fails. 

Proof plans are composed of building blocks called methods. A proof planning 
method (henceforth, we just write method) consists of a conjunction of heuristic 
conditions to determine when a proof operation should be applied and what its 
effects will be — the meta-level — and a tactic, which constructs the piece of 
proof which corresponds to the method — the object-level. A proof plan consists 
of a sequence of method applications which, at the meta-level, proves the ini- 
tial conjecture. Since, however, the meta-level logic is informal and heuristic in 
nature, this does not in itself constitute a proof of the conjecture. Once a proof 
plan has been found, the tactics which correspond to the methods from which 
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the proof plan is composed are combined to make a compound tactic, which can 
be executed to give an object-level proof. 

Since proof planning allows us to carry out heuristic, and thus practical, 
reasoning, while guaranteeing correctness through the corresponding tactics, it 
provides us with an ideal paradigm for combining logical rigour with usability. 



3 The Relationship of Schemas to Proof Planning 

Each method has five slots: an input pattern, preconditions, effects, output pattern 
and a tactic. The method is applicable to a meta-level goal if the goal matches 
the input pattern and the preconditions and effects are satisfied. The resulting 
variable substitutions are used to instantiate the output pattern and the tactic. 

By contrast, a schema has only three slots: an input pattern, conditions, and 
an output pattern. The schema applies to a goal if the goal matches the input 
pattern and the conditions are satisfied. The resulting variable substitutions are 
used to instantiate the output pattern. 

The similarity between the two formalisms is clear. The main difference is 
that schemas have no tactic slot — this is crucial. The tactic part of a method 
provides us with a criterion for the correct application of the method. This in 
turn frees the preconditions and effects from this obligation, and allows much 
more flexible, human-oriented reasoning to occur in them. Since schemas lack this 
slot, it is either the responsibility of the schema conditions to ensure correctness, 
or the correctness issue is sidelined. 



4 Augmenting Schemas with a Heuristic Component 

In H a rigorous formulation of program synthesis schemas called frameworks 
is proposed. Application of such a schema involves choosing instantiations for 
its open symbols and proving that the required framework axioms are satisfied. 
Schema frameworks can be used to encode general program synthesis strategies, 
for example divide-and-conquer Q. Schema frameworks do not contain heuristic 
information for deciding when they should be applied. Rather, they contain just 
the information needed to ensure correctness. 

Drawing on the analogy of Q we propose that schema frameworks should be 
implemented as methods. This entails carefully dividing each schema framework 
into object-level and meta-level parts. A good first approximation is to imple- 
ment the technical proof conditions of the schema as a tactic. The corresponding 
method has legal preconditions which determine when the tactic will be appli- 
cable, but also has heuristic preconditions/effects which can decide when it is a 
good idea to apply the framework, and can suggest sensible instantiations for 
the framework’s open symbols. 

The development of proof planning has been partly driven by the need for 
techniques for automating program synthesis and verification. We therefore al- 
ready have a catalogue of techniques which address the kinds of goals which 
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arise during synthesis and verification. In particular ripple analysis and rippling 
B are techniques for selecting and applying induction schemes which are appro- 
priate for proving a particular conjecture. Induction is vital for reasoning about 
recursive programs, and many algorithm design tactics (e.g. divide-and-conquer) 
correspond to induction schemas, suggesting that ripple analysis could also be 
useful in selecting algorithm design tactics. Middle-out reasoning Q provides 
a way of finding appropriate values for unknown (open) symbols in a proof by 
progressively instantiating them as the proof proceeds. Proof planning can be ap- 
plied to higher-order logic Q, which is important for reasoning about programs. 
These techniques (amongst others) should be useful not just in the selection and 
application of schema frameworks, but also in satisfying the proof obligations 
which arise. By implementing them as methods, schema frameworks can be in- 
tegrated into and benefit from our existing proof plans for program synthesis, 
verification and transformation. 

The adaptation of schema-based techniques to proof planning promises to 
offer advantages to proof planning. In particular, schema-based techniques offer 
a body of knowledge on program synthesis and transformation, and aspects 
of schema-based techniques, in particular the use of second-order patterns and 
constraints in their specification, could also be exploited in methods. 

5 Conclusions 

Schema frameworks are very similar to the methods used in proof planning. 
An integration of the two techniques would be beneficial for both. Proof plan- 
ning provides a uniform mechanism both for deciding which frameworks to use 
during program synthesis (or transformation), and how to use them, and for 
satisfying proof obligations which then arise. Techniques developed for proof 
planning promise to be useful for automating schema application. 
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The 17 logic, is designed to specify, to reason about and to synthesize im- 
perative programs in an object oriented language, namely C++ . There exists 
a lot of systems where computing-by-proof is possible but there are based on 
more or less classical logics and produce A-expressions. We make the distinction 
between programming and computing. Functional programs are obviously in the 
second category. Even if imperative programs can be modeled with functions, 
thanks to denotational semantics, this is not realistic. We are interested in the 
first category: we want to synthesize programs doing actions. 

Handling actions requires a particular formal system. It has to be construc- 
tive, i.e. to support Disjunction Property and Existence Property. Then, it must 
be resources aware, for instance linear in the sense of J-Y. Girard. Finally, it 
has to at least express concurrency, sequentiality, causality and nondeterminacy. 
Sequentiality is obtained using non commutative versions of some usual linear 
connective. Causality is obtained by an ad hoc new connective. 

The system is able to handle action formulae such as “to move the block 
X on the block y” and situation formulae such as “the block x is on the block 
y”. We consider a situation A as the action “to do things in such a way that 
the situation A holds”. Thus, everything is action. A mathematical formula is 
a modalized situation formula as in Linear Logic: the modality says that the 
formula is resource free, it can be duplicated or erased as we need. 

Connectives will be used to describe and combine actions but they are still 
used to describe and combine situations and mathematical propositions. Therefore, 
our connectives have two meanings, one in term of actions and one in term of 
situations. For instance, the first linear conjunction {A 0 B) has its usual linear 
meaning when A and B are situations: both A and B are true and available 
at the same time. But if A and B are actions, then {A ® B) is the action of 
executing concurrently A and B. However, there is only a single axiomatization 
for both meanings. 

In order to use the system, we write down a set of extra-logical axioms 
describing the knowledge about the problem. For instance, in the World of Blocks, 
there are axioms to say that there is always a free place on the floor and there is 
one axiom describing a move of a single block. Secondly, we have a description 
of an action. E.g., \/x,y-top{x) ® on{x, y) top{x) ® on{x, floor) 0 top{y) is 
a simple formula saying that we can move any top block x from its support y 
onto the floor. Then, we prove the action. And Anally, we automatically extract 
from the proof a realization of the action formula. 

The realization is an object in the sense of object-oriented programming. It has 
the method proue() which executes the proved action and returns an appropriate 
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result. The logic is exposed as a sequent calculus. Theorems are sequents of the 
form: 

Ri : , i?2 : ^2, , Rn '■ An h 5i : i?i , ^2 : i?2 , ■ ■ ■ , Sm '■ Bm 

meaning that if Ri realizes At for i G [1, n] then Sj realizes Bj for j G [1, m]. On 
both sides of the entailment sign h, the realized formulae are implicitly linked 
by a conjunction. It means that all formulae and all realizations are available 
at the same time. The Ri,i G [l,n] are all different realization variables. The 
Sj,j G [1, m] are realizations built using the Ri,i ^ [1; individual variables 

occurring in the formulae i?i, . . . , Bm. We also assume that the Ri, i G [1, n] are 
independent, i.e. they can be executed in any order, sequentially or concurrently, 
without changing their semantics. 

The axiomatization is difficult because an axiom or a rule must describe 
everything that has been done. Then comes the fact that realizations are impera- 
tive programs which do not have the referential transparency property: when and 
where executing them is crucial. We must be able to build the realizations of 
the conclusions from the realizations of the hypotheses in a sequent without any 
assumptions on them except their independence. The axiomatization is not clas- 
sical because of the fully conjunctive nature of our sequents, it has an interesting 
impact on the proof structure. The three structural rules are given Fig.J 

X : r \- X' : r' (id), identity-exchange rule 

X : r^n-. A y : Ah S : 0 

(tr), transitivity rule 

X ■. rh [TZ/y]S : 0 

X : rhTZ: A 

(mn), monotony rule 

X ■. r,y ■. 0 h Tz : A, y ■. 0 

(*) X' : r' is a, permutation of X : F. 

Fig. 1. Structural rules of 17 logic 

Besides the classical tree structure of proofs, the transitivity axiom allows a 
linear structure. Using the rules above, we admit Oi,F, 6*2 b 6 >i, A, O 2 as a gener- 
alized instance of an axiom Fh A. Using linear proof and generalized instances of 
axioms, proofs are much simpler than classical tree-like proofs. E Zarpas showed 
that human and automatic search for proofs is less complex. Note that in this 
scheme, axioms are better than inference rules. 

Besides these axioms and rules, we always have a method to build the realiza- 
tions of the conclusion formulae from the realizations of the hypotheses. A ® B, 
A times B, is both the first linear conjunction and the concurrent execution of A 
and B. We detail Fig.^some of its axioms to show the problems encountered in 
a formal system about actions. Firstly, we remark the unusual axiom stating the 
commutativity of 0 . This is due to the fact that a formula A 0 B, concurrent 
execution of A and B, cannot be split into an execution of A and an execution 
of B to be recombined into B ® A. Secondly, we remark some redundancy of 
axioms. This is due to the fact that operational semantics of the conclusions (in 
term of realizations) are not the same. 
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A,B'r A® B 
Ah C 

A® B h C ® B 



A® B h B ® A {A® B) ® C h A® {B ® C) 
Bh D 

A® {B ® C)h {A® B) ® C 

A ® B h A ® D 



Fig. 2. Some axioms for 0 



Here follows the unformal descriptions of some of the connectives. A^ B, A 
then B, is the sequential execution of A and B. From a logical point of view, it 
is some non-commutative version of the 0 conjunction. A > B, A prefix B, has 
no logical meaning. In term of actions, it means doing B but beginning by doing 

A. That is: A is the first thing to do in order to do B. After, only consequences 
of B are valid. Following the corresponding linear conjunction, A & B, A and 

B, means that we have the choice of doing A or doing B but only one of them. 
0 is roughly the same disjunction as in Linear Logic. In term of actions, doing 
A 0 H, A plus B, means doing A or doing B without any way to know a priori 
which one. A => B, A implies B, has its usual linear logic meaning. In terms of 
actions, it means that we can do B if we know how to do A. A ^ H, A causes B, 
means that doing A causes the execution of B. This connective could be useful 
for specifying event driven programs such as telecommunication protocols. Vcc • A 
has its usual linear logic meaning. In terms of actions, it means that we can do 
[t/a:]A for one chosen t. 3x ■ A has its usual linear logic meaning. In terms of 
actions, it means that there exists a witness t such that we can do \t/x]A. Doing 
!A is doing A but the modality “!” means that the formula can be duplicated or 
erased as we want. Typically, it is used for actions or states which do not need 
any resource to be done. 

The axiomatization of these connectives is complete except for the causal- 
ity connective and for the existence quantifier. The realization have been im- 
plemented in the C++ programming language, the system has been successfully 
applied to the World of Blocks problem. For instance, to move a stack of blocks 
one have to prove : 



/ stack{s) 


stack{s) 


0 


0 


top{s) 


top{s) 


0 


^ 0 


on{s, c) 


on{s, d) 


0 


0 


V top{d) 


top{c) 



From the proof, one builds a realization which realizes the move of the stacks of 
blocks. Of course, proving such theorems requires particular rules for iterating 
an operation. The system has been applied to the similar problem of the Towers 
of Ha no. Finally, we are applying it to ordinary computer algorithms involving 
programming variables. A few documents about fi logic are available by the Web 
at the Internet adress: http://www.enst.fr/~bellot/DOCUMENTS/index.html. 
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1 Program Transformations: An Emerging Paradigm 

Traditional programming paradigms revolve around mapping a single require- 
ments specification into a program. As less and less software is developed from 
scratch, and more and more is developed from existing software artifacts, this 
traditional paradigm is growing less and less predominant. Paradigms that are 
gaining ground include: 

— Program adaptation, whereby a program is modified to satisfy a specification 
that it does not originally satisfy; this occurs in adaptive software mainte- 
nance and in white box software reuse. 

— Software Incrementation, whereby a program is modified to have an addi- 
tional functional feature, while preserving its current functional properties. 

— Software Merging, whereby two (typically) similar software products are 
merged into a single product that cumulates the functional features of each; 
this arises typically when the two products are obtained by software incre- 
mentation from a common base version. 

— Software Composition, whereby various existing reusable assets are composed 
together (by means of application-specific code) to produce a prespecified 
software application; this arises in component-based software development. 

All these paradigms can be characterized by the following premise: they map a set 
of specifications (or programs) into a resulting program. It is possible to model 
these paradigms by a process of correctness-preserving stepwise transformations; 
unlike traditional programming calculi, these transformations joggle more than 
one specification (or program) at a time. 

2 A Calculus of Programming by Parts 

In I we discuss a refinement ordering between relational specifications (denoted 
by C) and discuss its lattice properties; also, we recognize that complex specifica- 
tions can naturally be structured as aggregates of simpler specifications by means 
of lattice operators (where the join is denoted by U). In ^ we use the lattice 
structure to derive a calculus of program construction by parts, whereby the so- 
lution to a complex specification is derived by focusing on the sub-specifications 
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in turn then merging their solutions into a solution for the aggregate specifica- 
tion. To support this program derivation method, we provide the following tools: 
1) A specification/programming notation that supports specification structur- 
ing (using lattice operators) as well as program structuring (using programming 
constructs). 2) A set of guidelines for deriving partially determined programs 
from component sub-specifications. 3) A set of rules for combining partially de- 
termined programs into (more) completely determined programs. 

This programming calculus, dealing as it does with more than one specifica- 
tion simultaneously, serves as a basis for our foundation for program transforma- 
tions. In the next four sections, we briefly review how it can be adapted to four 
distinct patterns of program transformation, namely: software incrementation; 
software merging; software adaptation; and software composition. 

3 Software Incrementation 

We consider a software system C and a feature F that we wish to add to C, and 
we are interested in how to augment C so that it has feature F. Our position is 
that this problem amounts to refining the specification CUF. Note that although 
C is a program, we can write it using our specification notation (we have rules for 
doing that, given in Q). Our calculus of program construction by parts enables 
us to determine which part of C may be modified to accommodate the change 
imposed by F, and to ensure that the change in question does not alter the 
current functional properties of C. 

4 Software Merging 

We consider two versions, say V and W, of some software system, and we are 
interested in merging them into a single version that has all the features of V and 
all the features of W. We view this problem as that of refining the expression 
V U W. Because V and W stem presumably from a common original system 
by incrementation, it is reasonable to expect that large portions of V and W 
are common, and that their differences are localized. Our calculus allows us to 
match up homologous parts in V and W, to identify subsumpption relationships 
between homologous parts, and to guide modifications where necessary. Also, 
it produces verification conditions that ensure that the functional features of V 
and W are preserved and cumulated as V and W are merged. 

5 Software Adaptation 

We consider a software component C and a specification K; we assume that C 
does not satisfy specification K, but we have reasons to believe that it can easily 
be modified to satisfy it. This problem does look like the refinement of AT U C, 
since it proceeds by considering information from two speciflcations/programs, 
but differs in two significant ways: First, whereas the refinement of K LiC seeks 
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to satisfy both K and C, the modification of C to satisfy K really seeks to satisfy 
K only — but expects to use C towards this end. Second, whereas traditional 
refinement oi K Li C proceeds by drawing semantic information from K and C 
interchangeably, the adaptation of C to satisfy K proceeds by drawing syntactic 
information from C (since we want to use the structure of C as a guide for 
our solution) and semantic information of K (since we must satisfy K, not C). 
To acknowledge the asymmetry between the roles played by K and C in the 
adaptation of C to satisfy K, we write the expression to refine as K 1>C, and we 
derive slightly different refinement rules for the l> operator than we had for the 
U operator. Space limitations prohibit us from presenting these rules, and from 
giving an illustrative example. 

6 Software Composition 

We are given a software system S in which we must integrate a component C to 
fulfill some function F. Because C does not refine (subsume) F, the component 
cannot be integrated verbatim; on the other hand, we assume that C is a COTS 
product, so that we have no access to its code, but can only add code around it 
to satisfy F. We view this problem as that of refining the expression (F' U C), 
where F' represents the weakest (least refined) specification that satisfies the 
condition: F' U C □ F. Intuitively, F' represents the weakest requirement that 
must be satisfied, in addition to C, in order to satisfy F. In | we discuss how 
F can be satisfied by inserting code to do preprocessing (upstream of C) or 
postprocessing (downstream of C) to satisfy F. 

7 Conclusion 

In this paper we briefly present a calculus of program construction, and we 
discuss its use for recent software development paradigms, such as software in- 
crementation, software merging, software adaptation and software composition. 
Several authors have advocated using the join operator in the refinement of com- 
plex specifications Recent work of Hehner | includes laws of refinement 

for join-structured specifications. The work presented in this paper differs from 
other programming calculi by the fact that it deals with new software develop- 
ment paradigms rather than traditional program construction. 
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1 Introduction 

Okumura and Matsumoto have published Q] examples of logic programs us- 
ing a data structure they call “layered stream,” especially suited for completely 
traversing a search space in a deterministic manner A layered stream is 

a representation of a list of lists, in which common heads of adjacent sublists 
have been factored. This factorization allows the pruning of several branches 
of the search space in constant time and is also a source of parallelism p. 
147]. The published examples include the V-queen problem and “instant in- 
sanity” (a precursor of Rubik’s cube). Each such deterministic, layered-stream 
program supposedly performs exhaustive search over the space generated by 
some nondeterministic, naive program. However, a method converting a non- 
deterministic program into a corresponding exhaustive-search, layered-stream 
version has not yet been proposed, as far as we know. Layered streams have thus 
remained difficult to use |3] p. 408], since the programmer must be concerned 
both about factorization of heads and exhaustive search. We build upon the 
work of Okumura and Matsumoto by showing how to translate nondeterministic 
programs into exhaustive-search, layered-stream form. Our method is restricted 
to generate-and-test programs fitting a certain schema. 



2 Layered streams 

We now give some basic definitions of layered streams. 

Syntax. A layered stream is recursively defined as follows. 

— begin and [] are layered streams. 

— [A* As] Is] is a layered stream if A* As is a *-pair and Ys is a layered stream. 
Now we define *-pairs in terms of layered streams. 

— A* As is a *-pair if As is a layered stream. 
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Semantics. Let Xs denote the list of lists represented by the layered stream or 
*-pair Xs. Then 



begin = [[]] 



[X*Xs|ys] = Ts 

where • denotes list concatenation. A *-pair X^Xs represents the list obtained 
by inserting X in front of every list in Xs . 

X^Xs = X oTE 

Note that a layered stream having only *-pairs that represent the empty list will 
also represent the empty list. This allows us to include “garbage” at any level. 
For instance the layered stream: 

[ 1*[3*[],4*[2*[]]], 2*[4*[l*[3*&e5m]]], 3*[l*[4*[2*&e5m]]], 4*[1*[3*[]], 2*[]] ] 

represents [[2, 4, 1, 3], [3, 1, 4, 2]] and is also the answer to the four-queen program 
of P and the goal ^ four Queen {begin, Z). 

3 An exhaustive-search meta-interpreter for chain 
programs 

3.1 Chain programs 

We define a chain program as a definite program such that all its binary predi- 
cates are defined only by clauses of the form: 

p{Xq, Xn) ^ qi{Xo, Xi), q 2 {Xi,X 2 ), ..., (1) 

or p{{t, Xs),[t'\Xs]) ^ test{{u, Xs)) (2) 

where the X^’s are distinct variables, var(u) C var(t), and var(f') C var(t). We 
use angled brackets ( ) as a function symbol of a term grouping inputs and 
outputs. 



3.2 An exhaustive-search meta-interpreter 

Obtaining all answers for a chain program and a goal <— p{xq,Z) translates 
to evaluating the expression {(xq,xo)} ; P, where denotes relational com- 
position and P is the relation denoted by p. We have to evaluate relational 
expressions of the form: 



{(xo, yi), ■ ■ ■ , (xo, yfc)} ; (Qi ; Q2 ; ■ ■ ■ ; Qm) 
{(xo,yi), ■ . ., (xo,yfc)} ; (Pi U P2 u . . . U P„) 



( 3 ) 

( 4 ) 
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We wish to achieve as much factorization as possible of partial solutions. This 
suggests using a left-to-right evaluation of Q and (Using other strategies 
leads to meta-interpreters having essentially the same behavior as either the 
continuation-based Q or the stream-based Q exhaustive-search methods.) The 
top-level predicates would be: 

comp{[], Xs, Xs) ^ 

comp{[Q\Qs], Xs, Zs) <— one_component{Q,Xs, Is), comp{Qs, Ys,Zs) 
union{[], Xs, []) ^ 

union{[Pj\Pjs], Xs, YsZs) <— onejunend{Pj , Xs, Ts), union{Pjs, Xs, Zs), 

append {Ys, Zs, YsZs) 

one_component{Q, Xs, Zs) <— defn{Q, Pjs), union{Pjs, Xs, Zs) 
onejunend{Pj , Xs, Ts) <— is_test{Pj), list_clJ.est{Pj , Xs, Ys) 
one_unend{Pj , Xs, Zs) <— cl_comp{Pj , Qs), comp{Qs, Xs, Zs) 

Layered streams can be introduced in the definition of the list_cl_test predicate. 

4 Beyond chain form 

It is easy to handle programs having a slightly more general form, quasi-chain 
form, where we generalize iQ to: 

Xq), Xn) ^ Xq), Xi), q2{{t2, Xi), X2), ..., qn{{tn, Xn-l), Xn) 

where var(ti_|_i) C var(ti)- 

If we fix the problem size, then all four layered-stream examples in Q can 
readily be written in quasi-chain form: the iV-queen problem Q p. 117], instant 
insanity, H p. 241], the “turtle problem” Q p. 266], and Waltz’s polyhedra-scene 
labeling Q p. 300]. Yet another generalization allows us to handle variable-size 
problems. 
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1 Introduction and Motivation 

Partial deduction is an important transformation technique for logic programs, 
capable of removing inefficiencies from programs As an on-line speciali- 

sation technique, it is based on an evaluation mechanism for logic programs. 
The input to a typical partial deducer is a program and a partially instantiated 
query. The instantiated part represents the information with respect to which 
one would like to specialise; the uninstantiated part represents the information 
not yet known. Therefore, all classical partial deduction techniques use top-down 
evaluation (or SLD-resolution) to evaluate the program parts that depend on the 
known input and generate a new program that computes its result using only 
the remainder of the input. Since the new program has less computations to 
perform, in general, it will be more efficient. 

In this work, we argue the need for a complementary partial deduction tech- 
nique that is based on bottom-up evaluation of a logic program: starting from 
the unit clauses, information is propagated upwards, and new facts and clauses 
are derived. The motivation for such a complementary technique is twofold: 

— It enables specialisation that is hard to achieve using a top-down approach. 
When specialising programs in which control information flows bottom-up, 
a top-down specialiser is often not capable of obtaining this information in 
time, in order to decide whether or not to continue the specialisation. 

— Sometimes, one wishes to specialise (or “concretise” ) a program with respect 
to a set of definitions, providing information that flows bottom-up into the 
program. Top-down, ^oaZ-directed specialisation often is not the most natural 
approach to achieve this kind of specialisation. 

To illustrate the control problem, consider the following example: 

fillJist(L, T, I, L) <— type{T, L). type{listl, [A]) 

filLlist(L,T,I,R) ^ fillJist{[I\L],T,I,R). type{list3, [Xi,X 2 ,X 3 ]). 

makeJist{T, I , R) <— fillJist{\\,T, I , R). 

The predicate makeJist{T, I, R) can be used to create a list of a fixed length 
(type T), with each element initialised with I. The result is returned in R. This 
example represents a class of recursive predicates that build up some structure 
between calls before a base clause of the predicate (ending the recursion) is 
reached, depending on the structure built. 
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Unfolding techniques, on which all top-down specialisers are based, are known 
to have problems with these. When unfolding e.g. makeJist{listS, I, R) without 
the information provided by the ^zst-predicate, it is impossible to detect whether 
the sequence 

filljist{[], fillJist{[I], ■ ■ ■) —^ fillJist{[I, ^ ... 

will eventually terminate. If, on the other hand, this recursive predicate is han- 
dled in a bottom-up fashion, structure is shrinking between recursive calls, re- 
sulting in the facts 
makeJist{listl, I, [/]). 
make Jist {lists, I, [/, I, /]). 

Apart from control, there are other reasons why a bottom-up approach might 
be preferred. Consider a program library M, in which n predicates are defined, 
all using the functionality provided by an abstract data type (ADT) to hide 
the concrete representation and manipulation of a data structure. Despite the 
advantages of abstracting information through several layers during program de- 
velopment and maintenance, every such layer of abstraction decreases efficiency. 
Therefore, it makes sense to propagate the concrete representation up into the 
program, to the places where it is really used, thus removing the overhead. This 
sort of information propagation can in principle be obtained by a top-down 
specialisation scheme. Achieving it in a general and completely automatic way, 
however, is far from trivial, precisely because of the bottom-up flow of control 
information. In particular, (Vanilla-like) meta-programs typically present diffi- 
culties of this kind. Moreover, a top-down specialiser needs a single goal to start 
specialisation from, which might not be available when specialising a library. Or 
the goal(s) will likely contain no information (all arguments free) since the latter 
flows bottom-up (further complicating top-down control) . 

So, in a number of cases, proceeding bottom-up is a more natural solution. 
Bottom-up transformation and specialisation has been considered occasionally 
before (see e.g. ^). However, to the best of our knowledge, our ongoing effort is 
the first attempt to achieve these in a completely general and automatic way. 

2 A Framework for Bottom-up Specialisation 

The most important contribution of this work, the details of which can be found 
in 0, is the definition of a formal framework, capturing the notion of bottom-up 
partial deduction. 

The transformation is based on a non ground Tp-operator, Tp , acting on 
sets of clauses instead of atoms, as in compositional semantics - ' | . In order to 
define a finitary transformation, the Tp -operator is combined with an abstraction 
function, mapping newly derived atoms (and clauses) onto more general clauses, 
capable of generating the former. This combination is denoted by an abstract 
Tp -operator, Ap. The resulting program can then be obtained from the least 
fixpoint of Ap, which can be ensured finitary through a suitable concrete control 
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scheme. The transformation is proven sound and complete with respect to the 
S-semantics: transformation of a program P results in a program P' having the 
same minimal S-Herbrand model fil as P. 

The defined transformation can be used as a stand-alone specialisation tech- 
nique, useful when a program needs to be specialised with respect to its inter- 
nal structure instead of a goal (as in the library-example). On the other hand, 
the bottom-up transformation can be combined with a more traditional top- 
down partial deduction strategy. In [3], we describe a concrete control scheme 
for bottom-up partial deduction, derived from top-down control techniques. As 
an illustration, it is shown that the Vanilla meta-interpreter can excellently be 
specialised by alternating a bottom-up transformation and a classical top-down 
specialisation - both using straightforward and fully automatic control. The 
same result can be obtained using a top-down component alone, but only at the 
cost of using a very sophisticated unfolding strategy. It is therefore expected that 
more involved combinations of bottom-up and top-down strategies will in gen- 
eral lead to specialisation techniques that are powerful, yet conceptually cleaner 
than one overall approach. 

Acknowledgments 

Wim Vanhoof is supported by a specialisation grant of the Flemish Institute for the 
Promotion of Scientific- Technological Research in Industry (IWT), Belgium. Danny 
De Schreye is a Senior Research Associate of the Belgian National Fund for Scientific 
Research and Bern Martens is partially supported by Esprit project 25503, ARGo. 

References 

1. A. Bossi, M. Gabbrielli, G. Levi, and M. Martelli. The S-semantics approach: Theory 
and applications. Journal of Logic Programming, 19/20:149-197, 1994. 

2. A. Bossi, M. Gabbrielli, G. Levi, and M. G. Meo. A compositional semantics for 
logic programs. Theoretical Computer Science, 122(l-2):3-47, 1994. 

3. Y. Gosmadopoulos, M. Sergot, and R. W. Southwick. Data-driven transformation of 
meta-interpreters: A sketch. In H. Boley and M. M. Richter, editors. Proceedings of 
the International Workshop on Processing Declarative Knowledge (PDK’91 ), volume 
567 of LNAI, pages 301-308. Springer Verlag, 1991. 

4. J. Gallagher. Specialisation of logic programs: A tutorial. In Proceedings PEPM’93, 
ACM SICPLAN Symposium on Partial Evaluation and Semantics-Based Program 
Manipulation, pages 88-98, Gopenhagen, June 1993. AGM Press. 

5. J. W. Lloyd and J. G. Shepherdson. Partial evaluation in logic programming. Jour- 
nal of Logic Programming, ll(3&4):217-242, 1991. 

6. W. Vanhoof, B. Martens, D. De Schreye, and K. De Vlaminck. Specialising the other 
way around. In J. Jaffar, editor. Proceedings of the Joint International Conference 
and Symposium on Logic Programming, Manchester, United Kingdom, June 1998. 
MIT-Press. 

7. W. Vanhoof, D. De Schreye, and B. Martens. A framework for bottom up spe- 
cialisation of logic programs. In Proceedings of the Joint International Symposia 
PLILP/ALP 1998, volume 1490 of Lecture Notes In Computer Science, pages 54- 
72. Springer- Verlag, 1998. 



Myrtle: A Set-Oriented Meta-Interpreter Driven 
by a “Relational” Trace for Deductive Databases 

Debugging 



Sarah Mallet and Mireille Ducasse 
IRISA/INSA 

Campus Universitaire de Beaulieu, CS 14315 
F - 35042 Rennes Cedex, France 
{smallet, ducasse}@irisa.fr 



1 Introduction 

Deductive databases manage large quantities of data and, in general, in a set- 
oriented way. The existing explanation systems for deductive databases 
give information in the shape of forests of proof trees. Although proof trees are 
often useful, this representation is not sufficient. We propose a tracing tech- 
nique which consists of integrating a ’’relational” trace and an instrumented 
meta-interpreter using substitution sets. The relational trace efficiently gives 
precise information about data extraction from the relational database. The 
meta-interpreter manages substitution sets and gives explanation on the deduc- 
tion. The expensive aspects of meta-interpretation are reduced by the use of the 
trace which avoids many calculations. The flexibility of meta-interpretation is 
preserved. It allows different profiles of trace to be easily produced. 

2 Debugging tools for deductive database systems 

Debugging tools for deductive databases must be useful for their various kinds 
of users: implementors who develop the deductive part, knowledge engineers 
who maintain the data, and end-users who query the database. Implementors 
need to get rather low-level pictures of executions of the deductive databases in 
order to understand and fix errors in the kernel. Knowledge engineers do not 
necessarily know the details of the implementation of the kernel, but they need 
to understand how the data, they add or modify, fit with the existing ones ; 
they therefore need to get pictures of executions abstract enough for them not 
to be overwhelmed by implementation details. End-users, in general, do not 
have an in-depth knowledge of computers, but they nevertheless have to rely 
on the results of the system. They, therefore, need to get very high-level views 
of executions to understand how the answers to their queries was produced in 
order to accept these answers. A key feature of a debugging tool for deductive 
databases is therefore its flexibility. It must be able to provide information and 
explanations at various levels of abstraction. 
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3 Driving a meta-interpreter with a trace 

A well known flexible technique to produce explanations consists in instrument- 
ing meta-interpreters (see for example Q). This instrumentation can be easily 
adapted to users’ needs. However, this technique is in general too inefficient. On 
the other hand, kernel developers usually instrument their compilers to produce 
some sort of low-level traces of executions. These traces are mostly intended at 
“private” usage and do not necessarily contain the information necessary to the 
explanations, but they are generated efficiently. 

We propose a tracing technique which takes the best of the previous two 
techniques. In Myrtle, we integrate a low-level trace with an instrumented meta- 
interpreter. The trace efficiently gives precise and low-level information about 
the extraction of data from the relational database. The meta-interpreter gives 
explanations about the deduction and allows more abstract views to be built. 
The expensive aspects of meta-interpretation are reduced by the use of the trace 
which avoids many calculations. In particular, the accesses to the relational 
database are not repeated. When necessary, the meta-interpreter uses the tran- 
sient information generated by the DB data extraction system, accessible via the 
relational trace. This feature is especially suited here as a deductive database 
program handles a large quantity of data. Avoiding to recalculate these data 
saves a significant amount of time. In addition, flexibility of meta-interpretation 
enables different traces to be easily produced, as illustrated at the end of the 
article. 

Two speciflcities of deductive databases prevent usual Prolog meta-inter- 
preters to be straightforwardly reused: set-oriented management of data and 
termination. Tuples of the relational databases are, in general, retrieved several 
at the same time, and not one at a time ; a possibly large number of tuples can be 
extracted from the base during a single access. Hence, in Myrtle substitutions are 
managed in a set-oriented way. Lastly, the restriction to Datalog and dedicated 
search strategies ensure that a request on a deductive database always terminates 

In Myrtle, we developed this technique for the Validity system based on 
EKS 0, which uses the SLD-AL technique to ensure termination, and the rule 
language DEL. 

Abstractions can be easily integrated in the meta-interpreter by instrumen- 
tation. In Myrtle, as an illustration of flexibility, three possible abstractions of 
the execution are proposed. We cite them in a growing level order of abstraction 
starting from the level close to execution. The first one, a relatively low level, is 
a box-oriented representation of execution, which is interesting for developers. 
The second one reflects the operational semantics level, it is a representation 
of the multi-SLD-AL tree. The last one is closer to declarative semantics. The 
execution is abstracted by a forest of proof trees combined with substitution 
sets. 

The meta-interpreter, the connexion with the “relational” trace of Validity 
and the three abstractions are described in details in 
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4 Conclusion 

The main contribution of this work is the integration of a relational trace and 
a meta-interpreter, which is, to our knowledge, original. The practical impact 
of such a technique is important. As already mentioned, users of deductive 
databases have many different profiles. The flexibility at reasonable cost offered 
by our technique enables the debugger to be adapted, in particular, to end users. 
They will better accept the results if they can understand how they were pro- 
duced. One can conjecture that such a tool can help widen the acceptance of 
logic programming technologies. 

The relational trace reduces the non determinism of meta-interpretation and 
avoids many calculations at debugging stage that have been already performed at 
execution. The meta-interpreter allows different abstract views of the execution 
to be constructed. 
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